8 Apr
2014
8 Apr
'14
3:55 p.m.
On Apr 8, 2014, at 1:47 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
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.)
OK :-)
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?
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)
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. 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.
> -
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. > - 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. 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