when can we avoid to have the white theme as default?
Locked
12
12
Re: when can we avoid to have the white theme as default?
 
|
Hi, Right. I thought I addressed the scrollbar problems and that you acknowledged that you see them now. As for the discomfort related to whiteness, it is a different problem that I would not mix with the ability of distinguishing a piece of UI.
Doru On Tue, Apr 8, 2014 at 11:16 AM, kilon alios <[hidden email]> wrote:
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: when can we avoid to have the white theme as default?
|
yes Tudor, I did not want to imply that problem was not solved with scroll bars. It was , I can see them now and thank you for your effort. Dont see this as just discomfort of white, I have hard time distinguishing GUI elements and yes that creates discomfort.
As a musician we have "dynamics" as a graphics artist we have "contrast" these are super crucial concepts for any artists. Why ? because they are crucial to the viewer and listener. Of course it has to do with how our brain process information and that differs from person to person. Pharo white theme is what should be taught in design classes as an example to avoid.
For example now I am typing this in my gmail , gmail uses a white theme, yet you can see gmail understands and respects basic Design principles. Still my eyes don't like all this white , but, they dont have a problem finding GUI elements and making sense of things.
In any case my opinion is just an opinion, get feedback from other people, try to find a common ground.
On Tue, Apr 8, 2014 at 12:40 PM, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
For example I can see 0.98, and 0.99 is hardly noticeable. But for me it’s not how much white you can do it. It’s how to make it beautiful.
Uko On 08 Apr 2014, at 07:02, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
On Apr 8, 2014, at 1:47 AM, Tudor Girba <[hidden email]> 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
Just to say thanks to your effort Doru. You really have a lot of patience to deal with all this :-)
Alexandre On Apr 8, 2014, at 6:40 AM, Tudor Girba <[hidden email]> wrote: > Hi, > > Right. I thought I addressed the scrollbar problems and that you acknowledged that you see them now. > > As for the discomfort related to whiteness, it is a different problem that I would not mix with the ability of distinguishing a piece of UI. > > Doru > > > On Tue, Apr 8, 2014 at 11:16 AM, kilon alios <[hidden email]> wrote: > Another big hater of the white theme in moose and pharo here. I can barely see those text fields , I have spoken here about my problem with scrollbars too, I have to really look intense and its tiresome and makes the usage hard for me. I already agree with most of points people have made. I was never comfortable with light themes, the ideal for me would be a dark theme but of course cause I took a look at Pharo theme classes and tried to make my own dark theme I realized the painful way that's easier said than done. > > > On Tue, Apr 8, 2014 at 9:21 AM, Guillaume Larcheveque <[hidden email]> wrote: > when I'm perfectly in the axis: 0.96 > > when I'm not in the axis: 0.8699999999 > > However lines have twice the height of the border so it' easier to see. > > I can understand that you want to have the less intrusive theme to put forward vizualisations but in my opinion at least the window that have focus should have more colors and contrast. > > > 2014-04-08 7:02 GMT+02:00 Tudor Girba <[hidden email]>: > > Hi Guillaume, > > Thanks. > > The contrast of the gray was reported before and I thought that we solved it by making the gray a bit darker. Finding this problem depends on the screen, and given that you have a less performant screen, could you please do the following experiment? > > Experiment: pick from the following picture the lightest gray that you see and then send back the number of the model (you can easily do this in GTInspector) > > view := ROMondrianViewBuilder new. > view shape rectangle > withoutBorder; width: 400; height: 1; fillColor: [ :each | Color gray: each ]. > view nodes: (1 to: 0 by: -0.01). > view verticalLineLayout gapSize: 10. > view > > Doru > > > On Sun, Apr 6, 2014 at 9:10 AM, Guillaume Larcheveque <[hidden email]> wrote: > The main problem was the border of each window. For someone who is not aware of every tool, they sometime missed the bottom of a window and they try to click on another one but were still on the previous one (this is just one problem that I remember). > > Because my goal was not to experiment the theme, I quickly moved users to the other glamourus theme. > > The problem is even bigger when you have a screen of bad quality like my acer laptop where I cannot see the border at all if I'm not right in the axis of my screen. > > > > > 2014-04-06 8:33 GMT+02:00 Tudor Girba <[hidden email]>: > > It's not quite so. It's just that we are not used to it. But, we can get used to with practice. Let's just start and in a year from now we will be better :). > > One way to do it is to talk about principles. For example, one principle I want in a basic theme is to use the least amount of graphical variables it can so that other interfaces that are built on top of it have the freedom to utilize the rest of the variables. Of course, the interface should still satisfy basic usability requirements like finding a piece of information. > > Another way to do it is to talk about actual cases that people have difficulties with and look at what can be improved there. So, what kind of information could not be found? What specific actions could not be carried out? > > Doru > > > On Sun, Apr 6, 2014 at 12:05 AM, Alexandre Bergel <[hidden email]> wrote: > This is amazing to see how user interfaces are so subjective and hard to formalize. At first, I was not happy with the white theme at all. But now, I find it nicer than the default theme. Unfortunately, I cannot say what i exactly like in the white theme. > > Alexandre > > > On 5 Apr 2014, at 05:42, Guillaume Larcheveque <[hidden email]> wrote: > >> I confirm that I'm always changing the theme. The main reason is that there is no contrast at all. >> >> For the usability experiments with people, I had a teaches on Moose with other INRIA engineers (who doesn't use pharo) and the first comment was that the look is not friendly at all and they had difficulties with it. >> >> >> 2014-04-04 22:13 GMT+02:00 Tudor Girba <[hidden email]>: >> Thanks for the input. >> >> If you say it like that there are little chances of changing anything. The only way we can improve is to know why something does not work. Only when we know the reasons can we start to react properly. So, please do let us know what does not work. >> >> Just because it is about the way something looks does not mean that we cannot have a structure discussion about it. >> >> Please note that I am not saying that the white theme is the ultimate design. It is not. But, to find other means of expressions we have to leave the classic one and build simple things in simple ways. The white theme has a small amount of visual variables which goes hand in hand with the philosophy of Pharo. This is something to nurture, not to push away. If something does not work for a reason then we look at it. For example, when the scrolling did not work, we changed the color. I want to spend the energy in doing that, but I need your input. >> >> Just for the record, I am doing similar usability experiments with people that do not know Pharo upfront, and they seem to have no problem finding their way. So, it is not quite as random as it might appear. >> >> Doru >> >> >> On Thu, Apr 3, 2014 at 10:20 PM, Johan Fabry <[hidden email]> wrote: >> >> For the record, I am not so happy with the white theme either. >> >> On Apr 3, 2014, at 5:14 PM, Stéphane Ducasse <[hidden email]> wrote: >> >> > Hi >> > >> > I checked here in rmod and I realized that NOBODY uses the white theme and I realized that I was not the only one to >> > get fedup with it. So when can it be not the default one? >> > >> > Stef >> > _______________________________________________ >> > Moose-dev mailing list >> > [hidden email] >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> Guillaume Larcheveque >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > Guillaume Larcheveque > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > Guillaume Larcheveque > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: when can we avoid to have the white theme as default?
|
|
I think that if we would be really serious about the themes we would do the following:
- Take three persons and ask them to perform some tasks and talk aloud to describe what they are thinking when they perform a task. with simply three persons that are not used to a theme you can debug many problems To me right now I cannot use the white theme. Getting less visual clue is a dead-end to me because this is not having less the right goal. The right goal is having a theme that is helping people to work and that it looks good. BTW when we debugged the font problems with igor, we were really frustrated because the debugger did not let us restart methods (they was no fly by help, no menus….) then we dod not know how in some cases we could get another debugger with more items (no ideas why) and we got some problem with keybinding in the workspace. We open an old workspace to be able to work!!! So of course we can think that igor and me are just two little idiots not understanding what we were doing. Now do not expect that people like Igor will spend their time fixing Moose problems (because this was a problem of Moose - adding fonts without adding them to the crappy ad-hoc registration mechanism was a Moose problem). Igor was nice to help me but do not cry in the future if people do not help because if the basic tools do not work well why people should freely spent their time helping us. Igor did it because I was forced to do it and we did it together. I was also frustrated because I also have something else to do than to fight with a debugger that did not have the default functionality. but icons do not work me. After that experience I was thinking that I should do a new jenkins job loading my version of Moose and do not say it around. I would imagine that everybody at RMOD would suddenly use this version of Moose because many people are getting frustrated. I did not want to start a war but I was ****REALLLLLYYYY**** frustrated. I could not see the input field, I could not get the workspace working and the debugger was wrong. So yes we can say that nautilus is bad but I use it daily and I have no problem to know where to type. Feel free to ignore this message, but when I will be really mad again I will create a jenkins job and only use this version. I fully understand Yuriy’s idea to have less Moose! And I will ask the people that wants me to help to only use this version that I can use. Stef _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: when can we avoid to have the white theme as default?
|
|
Hi Stef,
On Tue, Apr 15, 2014 at 11:44 PM, Stéphane Ducasse <[hidden email]> wrote: I think that if we would be really serious about the themes we would do the following: Thanks for the suggestion. I already did that. It is certainly not enough. But, I think at this point I am pretty much the only one spending time in this direction in Pharo. I am not saying that I am doing a good job, but at least I am trying :).
To me right now I cannot use the white theme. Getting less visual clue is a dead-end to me Right. Just for the record, the theme that is being used in Pharo was not liked at the beginning either. Now, it seems to contribute to the coolness factor in Pharo. The world changes :). But, it would be more useful to spend the energy on engineering, and engineering requires concrete things.
BTW when we debugged the font problems with igor, we were really frustrated because the debugger We open an old workspace to be able to work!!! I do not think you are idiots, but if you cannot say what problems you had it's hard to address them. For example, you say that there were no tooltips, but all actions have tooltips that behave exactly like any other tooltip in Pharo. If they did not appear you might have run into a Pharo bug, but I doubt it.
What do you mean by more items? More actions/icons? Or? What were you debugging? You know very well that these tools are not the ultimate tools. They are built by people that typically have other things to do, too. But, I think everyone is ready to listen to things and see how to improve. Let's just keep on being concrete.
Now do not expect that people like Igor will spend their time fixing Moose problems (because this was a problem of Moose - Thanks for looking into it, but Moose did not really have a problem with this issue. I did not encounter even one case in which I had to change the fonts after they were set in the setup (the Moose image comes with this setup already done). It's good that now we have a basic in-image font registration mechanism, though.
Igor was nice to help me but do not cry in the future if people do not help because if the basic tools do not work well I thank Igor and you. But, I still do not understand why you were forced to do it?
I was also frustrated because I also have something else to do than to fight with a debugger that did not have the You are mixing a bit things. We started from the theme, and now you talk about the debugger. Which one is the problem? Both? Equally?
After that experience I was thinking that I should do a new jenkins job loading my version of Moose and do not say it around. Feel free to ignore this message, but when I will be really mad again I will create a jenkins job and only use this version. I fully understand This is not really helpful, but the choice is yours :) Good night, Doru
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: when can we avoid to have the white theme as default?
|
|
We could not fix the problems and in addition records all the problems we got. Sorry. You know if a guy like igor (with me pair programming) cannot find a restart in a debugger may be this is that it was not there. I mean getting what we have now. and a menus with the action we have now We were debugging the broken registration.
Apparently you never pressed twice on the disable freetype fonts with Moose. Because it worked in Pharo but it brokes on Moose because fonts were not added to SourceFonts. Because some of our potential clients got the big red cross on their screen and several times. And they were donwloading Moose and not simply Pharo. So this is not just for fun that I had to fix that. Both. And even the inspector because some key binding where not working, so we were puzzled and we open an old workspace to be able to work and find the information we needed. Indeed. But at least you understand the frustration of people. This is not by accident that I started this thread. This is months that people here are switching automatically to get rid of the white theme. Stef
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |