On Mar 9, 2012, at 12:17 AM, Igor Stasenko wrote: > On 8 March 2012 23:24, Benjamin <[email protected]> wrote: >> >> On Mar 8, 2012, at 8:25 PM, Esteban Lorenzano wrote: >> >> Hi, >> >> I'm using Nautilus for my current projects since... well... couple of days, >> and I have some feedback: >> >> (yeah... maybe they are dumb reports, but that's because you did a great >> work with nautilus, I just have some really small observations :) >> >> 1) OB had double-click action: show hierarchy. I miss it a lot :( >> >> >> If you activate the "open a class on hierarchy" setting, it does the same :) >> >> Also, hierarchy button is too far away when I want to see the >> hierarchy... ok, if you don't want to add double click functionality... can >> it be a menu option? (show hierarchy (h)) >> >> >> Maybe I should switch the group button and the hierarchy button. It will >> make more sense :) >> >> Even worst: it swaps panels which is very confusing... but that leads to >> point 2 :) >> >> >> There are some good arguments to do that :) But I am quite fed up to tell >> them again and again ^^ >> >> 2) swap panel configuration is not working for me in latest pharo 1.4 >> >> >> Ie ? >> >> 3) I find "Class", "Instance" buttons very confusing. I liked more the older >> solution but well, I understand you want to improve visibility of comments, >> but then, I think class button would be better as a "toggle" button (those >> buttons who stays pressed) >> >> >> Do you have an example of such a button ? >> >> 4) bold for class side method and categories is too strong, I don't see any >> reason for that, we have panel titles and future ;) toggle button to know >> which side is. >> >> >> Some people (Laurent not toell who) complain about the lack of visibility. >> And indeed, I found than when you have multiples browsers, it helps a lot to >> find where you are in a second. >> >> 5) OB had a #browserIcon method on classes who changed class icon on >> browser. This is really useful for knowing different types/hierarchies like >> errors, announcements, morphs, etc. Again, this collides with "uncommented" >> icon, but I would like to have them back... >> >> >> There are icons for >> Morph/Erros/Announcements/Magnitude/String/Collection/etc... But maybe I >> could also add a mechanism to let each class defines it's own icon. >> >> 6) I'm sorry for saying this, but I don't like the icons, nor the colored >> options (source, bytecode, decompiled, etc.) at the side. I would prefer a >> combo on button panel... and better looking icons (yes Stef, FamFam icons is >> ok :) >> >> >> I will be really glad to use yours :) You know, I am kind of a programmer. >> It means that making icons is not my work. And due to that, it takes me ages >> to do them. >> I have no problem to change them at all, but I really don't have time to do >> them. >> > so then go finish arts and design schools (min 5 years each). and only > then you may get back and continue working on nautilus! Hurry up. :)
I will think about that :) >> 7) Why we have a button panel (which is in fact a toolbar) in the middle of >> the browser and not where it belongs: on top? this is a remain of OB, who >> took this from old Browser... but conceptually (as in usability terms), this >> is a not-good solution. We could think on change this and place the button >> bar where it belongs (and add some cool keybindings too) >> >> >> You can't say that the hierarchy button is to far, and ask for putting the >> toolbar on top ^^ >> It's here because it's close to the lists (where you spend 20% of your time) >> and also close to the source code (where you spend 80% of your time). >> >> 8) different sized buttons are a really bad concept. Yes... in Smalltalk >> this is very common: to create buttons with the size of text... but this is >> bad design because disrupts harmony, and that hurts to the eyes... and when >> something hurts, you try not to use it :) >> >> >> I can't agree more. But buttons are kind of a pain in the ass (because they >> are embedded into a group morph with its own layout etc). As soon as I can >> set >> vResizing: #rigid; hResizing: #rigid, I'll do it for sure ^^ >> >> >> yeah.. most of my observations are also for any other tool we have, and most >> are about usability... I humbly recommend (for all people doing GUIs), the >> lecture of this book: http://en.wikipedia.org/wiki/Don't_Make_Me_Think. It >> is for web design, but is also a great guide when you want to make things >> people like. >> >> (Also, reading apple design guide is a good way to notice some interesting >> things... those guys had invest an insanely amount of time and money in >> development them) >> >> >> I will try to find time to read them, but as I said, my exams are in 11 days >> so ;) >> > no. arts school first. I just finished my registration ;) > > ohh.. nothing is perfect. changes are not always better to what we had. > but staying is worst of everything. > just keep pushing. > > I can also easily tell what i don't like in Nautilus. Much harder is > to propose alternative. > I think that feedback about UI should always come with alternative, > explaining why you think its better. Or if one feels that old ways is > better he should argument that (an argument 'because i get used to it' > is WRONG argument ;). > > Today i had full day hacking using Nautilus. And found some bugs. Hope > next iteration they will be fixed. :) > There are some rough corners here and there, but overall impression - > it is quite good. > I will be starting giving more feedback once i will get used to it. > Because 1 day is too little to say anything definitive.. i need more > immersion to make my feedback more problem-oriented, not tainted by "i > don't like it because it different" attitude. I am waiting for your feedback so :) > >> >> Thanks for the feedback :) >> > > > -- > Best regards, > Igor Stasenko. >
