Hi, On Mon, 2006-04-10 at 17:37 +0100, Calum Benson wrote: > > Just as long as those offering advice really understand the costs of > > such changes. I don't think I can really properly understand them > > myself, but I imagine it's running into 10's of thousands of dollars > > when you add it all up. > > Very possibly, although of course you have to offset that against any > savings in support costs etc. that the changes bring too. It's > always difficult to cost-justify UI changes, although I do have a > book on the subject that I really ought to read sometime :)
Absolutely - I'm not entirely convinced we've done our homework there though. Obviously we should value the user experience a lot more than maintaining compatibility with the GNOME community - that's the 'right' thing to do, I'm just not sure we have enough information to make that call. > Well, the original rationale was to gradually introduce users to the > idea that there's a directory with their name on it containing their > Documents plus all their other stuff (i.e. their home directory), so > that if and when they saw it in Nautilus, they would equate it with > the place where all their stuff was. > > I do think it's going to be hard to do that in a meaningful way > though, and I think it would only take the merest whiff of "difficult > to implement" to convince me to replace it with the community Places > menu... although given my blog rant today about the state of Places > in GNOME, that's not necessarily a good thing either :/ (http:// > blogs.gnome.org/view/calum/2006/04/10/0) Ouch. That does seem a bit of a mess - not sure the current proposal really cleans that up very much though eg. 'Computer' vs 'File System' in the Nautilus Go menu. Still a big +1 from me for going with the community and trying to fix up the inconsistency there, rather than trying something new. Also amusing to see the 'Alt+Home' keyboard shortcut for 'Documents' menu item ;) > > Is it really useful to the developers we're trying to capture? It's > > not > > the most intuitive of interfaces either :) > > True, although show me a developer tool that has one of those :) Heh, yeah ;) > You do have a point, at-poke would be more useful if it also worked > with Java apps, and I don't think it does (not sure off-hand though), > so I'm inclined to remove it too. The a11y team wanted it on the > menus last time though, so that's possibly a discussion for them and > marketing to sort out between them. Hrm, I'd almost argue that it shouldn't even be installed by default - it's demo-ware, was a 30 minute hack to demonstrate a11y at a conference. > >>> o Save Screenshot/Take Screenshot - is the string change *really* > >>> that crucial? > >> > >> No, but it matches the title of the dialog that appears when you > >> select > >> it, which is needlessly different at the moment. Would want to > >> try and > >> get this change back to the community, certainly (as we would with > >> almost all of the proposed tooltip changes, probably-- most of the > >> current community ones are dire). > > > > I'd be happy with an upstream change - let's get it changed there > > before > > we change our menus, IMHO. > > Fine by me. Cool - I assume you've logged a bug on this? I'd be happy to create a quick patch for you if needed. > But... I've just been told again that the UI spec is to be considered > frozen as of today except for agreed changes based on Nevada users' > feedback (or, I guess, from other Sun usability folks), so I'm afraid > we'll probably have to postpone that exercise for now. Do you have any formal process of changing things in the spec? I'm not so sure we should be freezing the entire spec - it doesn't feel ready, although other sections are pretty solid. Anyway, my objections for the record - o Keeping the JDS 3 style menus. I'd much rather see Applications being rolled into the top level, and rethinking the Quick Start idea. o I don't like the current 'username' menu - I'd prefer working to fix the current bugs with Places, and going that route. Glynn
