Here's my opinions. Just for the record, I'm not a designer, but then I have seen things evolve for many years (since the Win 3.1 years) and even though I'm not an artist myself, I like to think I can see the details.
*Ribbon UI/toolbars* For starters, we might begin with the ribbon discussion. Of course, Microsoft introduced to the world at large (as general, sidestepping prior art discussion) the ribbon UI. Since then, it was abused in every corner of software development. I was really shocked the first time I saw Matlab's "new interface" (which for me looked pretty ugly and outdated). Anyway, it was just something to make it look newer, but for me seemed to allow the user to do less stuff. Really? Three tabs? Even though I didn't like it then, MS did a really remarkable job with Ribbon in the Office suite. They even counted how many mouse clicks were used for each function. But I think it is an interface better suited for switching "thinking modes". You don't have too much of that in a code editor. You may even have some modes, but probably not enough to group in tabs. Back to what's important, it appears that at least for now MS agrees: just look at the latest VisualStudio edition (2013, first image I googled to): I chose this shot for a few different reasons. To begin, it doesn't even have a code editor per se. This is a characteristic of the very generic IDE that VS is. The point is: even in a no-code "mode", it still doesn't have ribbon. Hell, even Office 2013's VBA editor doesn't have then, though it still looks very ugly, uglier than it used to be in Win95 days. The other point I want to make is that the general trend in UI design seems to be quite minimalistic. Just look at Google's new Paper style for Android and other stuff. Compare newer GMail, Drive, Facebook, <pick your site> to the older ones. They now all point toward minimalism. Avoid lines for useless division (the double-line problem pointed earlier is caused by the tabs themselves, that draw a line above that of the line drawn by the code widget). Use colors to differentiate, but avoid too much color, like colorful icons, gradients, unless it's absolutely needed. I might say that it is a good time for me, who have always liked plain colors, so I might be biased, but I also add that I don't like the Metro UI, for example, that restricts users action. By the way, minimalism also tends to enhance performance when drawing. In contrast, toolbars are very straightforward. They're everywhere and all users know how to handle them. Some even know they can be hidden or showed with the usual "View" menu. For the record, I like a lot that I can quickly change the console's working dir from the toolbar. This is specially helpful when doing multiple/separate scripts, or scripts that handle files and directories. For completeness, fortunately I do have a Full HD (wide)screen at home, but at work I did think the toolbar buttons were too big. That is an advantage with a Ribbon "done right". Just look what happens when we resize an Office window to make it smaller. This: [image: Imagem inline 2] becomes this: [image: Imagem inline 3] which becomes this: [image: Imagem inline 4] Talk about graceful degradation! Now again: this is very hard to do, and I really don't think we even should, for the reasons above. *Icons* Shifting the subject a little, I liked a lot the FontAwesome project. I just might add that we might render the glyphs in-app (with QFont and QGraphicsTextItem), but I don't think we should actually do that. It would probably impact performance at a critical time: the startup. So, I'd go with the PNG conversion too, but would add a little tint color to differentiate groups of icons (run vs debug, for example). That would mostly unify the icons. If some icon isn't available yet, it wouldn't be too hard to do one in inkscape. Specially since they're so minimalistic. Adding to that, when I went to Anaconda (I noticed this after version 2.1.0) the window icons weren't put properly in the Windows taskbar, displaying [image: Imagem inline 1] instead. I also noticed that Spyder uses the same code that got my plugin running with the correct icon, so I think it is an issue with Anaconda's packaged QtSvg. Another reason to go with PNGs. *Debug* Yeah, it is weak. I don't even use it, since it's faster for me to alt-tab to a command prompt, press up and run last command. The debug output is with old print() or with spyder's debug_print(). GUI stuff is never easy to debug, even with a debugger. *Object Inspector* It's quite slow for me. I remember when I would type at the console and wouldn't have to press Ctrl+I and wait for the help to show up. It even was better help then (sometimes just a line for the specific function isn't enough and it's better to point to the object's point where the function appears). It was blazing fast (no wait) and hassle-free (no need to Ctrl+I). *Fixed shortcuts* This was suggested in the matrix editor PR comments. This is a BAD IDEA. Shortcuts should be visible to users. This allows them to actually find the shortcut in the first place. I'm an advocate of having every action available through a menu, even if it's several levels deep (Ctrl+B will do when there's an Format>Paragraph dialog but there's the button with the shortcut, for example). But it creates a lot of trouble having a Ctrl+dot global shortcut for the quick matrix insert when there's no menu entry for it and no configuration item in the Tools>Preferences>shortcuts dialog. Besides, it will all blow on the user's face if he actually tries to assign that shortcut to some command. Two outputs: 1) he does assign the shortcut and the program may act erratically, with the shortcut having different behavior on different parts of the program; or 2) he cannot assign the shortcut, but doesn't know why, since no other entry has that shortcut. Except on option 3) the program blows on the user's face, crashes with a wrong config file and the user has to reset and reconfig everything (if we don't do enough testing). A possible alternative to unclutter the UI is Office's way to show shortcuts (hold Alt and it shows the shortcuts, and the user compose the shortcut with multiple keys). The problem with this is that it works better for Ribbon interfaces (might be a plus for handicapped users that prefer keyboard shortcuts instead of handling the mouse to get a tooltip). *Start screen* Sucks, unless it is used only for the very first time. It sucked when Eclipse added that (at least for me), specially since they did add functionality to it that was harder to get through different means. Result: kept having to go to it to change to some perspectives. It is fine to have some examples for noobs, though but for experienced users, it's better to open to a new script to start coding or as a scratchpad for the console. Better yet (in my case) is to just open the files that were open when the window was closed last time (as Spyder already does). Nice to start easily from where we stopped. I guess I couldn't keep it short (again), but those are my views. Cheers, Ronan -- You received this message because you are subscribed to the Google Groups "spyder" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/spyderlib. For more options, visit https://groups.google.com/d/optout.
