On Apr 8, 2014, at 1:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Thanks for the detailed remarks. This is an excellent step.
My pleasure :-)
As I figured, people have a problem with handling Nautilus. In my opinion, making Nautilus work properly is a class of problems of its own because currently it uses widgets in unfortunate ways. See my comments below.
Are you using other tools where you see problems? Perhaps some GT tools or something Glamour related?
I am not so sure that it is only a Nautilus issue (while I do agree that Nautilus is playing fast and loose with how to use widgets). Other tools give me the same feeling, although I cannot quantify it so easily right now.
- text fields for searching and history navigator drop down are without an outline that indicate that these are text fields
It's true. I am not happy at all with how the drop downs look. I could not make it to work properly because it hardcodes too many things and I did not have the time to look at it.
That being said, both text fields are actually clearly indicated due to the text that goes with them. I doubt that people will not be able to find where the field is.
For me it was confusing actually. I was wondering why this package name was in gray, and then wondering why it had this strange name, and then only realizing it was a search field. Sure, I found it in the end, but this kind of confusion just annoys me. (Yes, I am old and cranky.)
I am actually torn with drawing borders around the text fields. Adding a border around text areas would imply adding borders around lists as well and this will add significant noise. On very few occasions I see problems with having two text fields next to each other. This can happen in the GTInspector when browsing the code in both panes. However, this situation will be solved with a new widget.
I think you can treat text fields and text areas differently from lists. In lists the user does not add or edit (usually), while in text fields/areas this is the case (usually). For me, this merits them having a border, while lists do not need them as much. Maybe try putting borders only around text fields/areas for some time and see how it goes?
- for drop down opening button it's is not clear it’s a button.
Agreed. This is a problem induced by the implementation of the drop down widget. I will try to solve it somehow.
OK :-)
- background of the class toggle is different from the buttons.
Well, that is because it is not a button. It's a checkbox morph. I would not optimize a whole theme just to make this unfortunate choice more fortunate.
Yet it does illustrate a combination of buttons and checkboxes in a UI. I wonder if there is no way to make such combinations look better?
- it’s not clear that buttons are buttons because the conventional borders around buttons are absent (holds for both the traditional ones as the show source code / show byte code / etc…)
When you place those button on a white space, it is actually quite clear.
But I really don’t like it when buttons don’t have borders (not only in the white theme BTW, e.g. iOS 7 as well). It’s such a deeply ingrained and fundamental convention that I don’t like it when it is broken. I’ve read multiple UI experts complain about that (e.g. in iOS 7 reviews)
The buttons you mention did not receive a particularly happy design:
- the first two represent states that would be better modeled as tabs. I guess this will not happen.
- the last three require some space in between. Just doing this would make things simpler.
Agree, and I know this is not an issue of the white theme.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile