On Wed, Jan 28, 2015 at 3:11 AM, Ronan Paixão <[email protected]> wrote:
> 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.
>
Microsoft did, and possibly still does, require that anyone using a Ribbon
interface sign a license agreement with Microsoft. This would need to be
checked. If this is still the case, it could very well conflict with
having Spyder as MIT licensed. There is also no built-in Qt ribbon widget,
which would mean either a third-party one would need to be obtained (which
would probably be C++), or it would need to be re-implemented from scratch
(which would be a lot of work).
> 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.
>
>
That is the trend for basic applications doing simple thing for everyday
users. I don't see such a trend with technical applications doing complex
things for technical users. That is not to say that making things better
organized is bad, it is definitely important, but I do not think simplicity
for simplicity sake is always the best solution. You need to think first
about what you are trying to accomplish and who will be trying to
accomplish it. The very fact that spyder is for people who want to write
their own software immediately rules non-technical people doing simple
things.
Fast. Powerful. User-friendly. Now choose any two.
- Eric Daniels
> 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.
>
Colors are, and I think should continue to be, determined by the native
widget style.
>
> *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.
>
>
I am very strongly in favor of applications that fit in nicely with the
user's own environment. This means native theming, native layouts, and
also native icons. I think spyder should look as much like all the other
applications a user uses as possible. People who are used to a particular
icon style and the metaphors that icon style uses should not have to learn
an entirely different style just to use one application.
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).
>
I mentioned this is not possible in Qt with the meta ("win") key. To
expand on that, it is not possible with any of what Qt considers to be
"modifier" keys (shift, ctrl, alt, and meta).
On Wed, Jan 28, 2015 at 3:11 AM, Ronan Paixão <[email protected]> wrote:
> 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.
>
--
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.
