just want to correct myself. I used Nautilus before.. but it is not my "all day" tool, because there are myriads of images i had to work in, and most of them don't have nautilus. That's why i don't feel myself in a position to give feedback at this point.
On 9 March 2012 00:50, Benjamin <[email protected]> wrote: > > 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. >> > > -- Best regards, Igor Stasenko.
