> To Seth, I think we need to just slow down :) *grin*. Definitely, especially since I planned to take a brief vacation from major free software involvement post-HIG release and concentrate on my RealJob(TM) and RealLife(TM) for a while. I actually (horrors) didn't read e-mail yesterday :-) > 1: How about nothing concrete on *anything* is done for a few days. Again, > many of us have never heard of or seen the HIG before, and there's 130 very > densely packed pages of information there to digest. So lets give everyone > who is interested a chance to go through it in more depth. > > Specifically there are several people who should be involved in this > discussion and haven't, so far. I'm thinking here of Ryan Cumming, Malcolm > Hunter, Stephen Binner, who have between them done the bulk of the work > bringing KDE into line with the existing style guide and Waldo Bastian, who > originally wrote most of it. > > On first reading, it appears to be very GNOME specific, a closer reading shows > that it needn't be, and what there is that looks GNOME specific, we can > provide alternate KDE content for. I think its important to remember that the actual writing is at most a quarter of the work. Deciding *what* sort of design is best, *why* its best, and then working that through a review process (as well as considering its implications in terms of consistency between all the guidelines) is a much more time (and of course mentally) intensive process than the actual words on the page. Almost none of the design work is specific to the toolkit; that is to say our reasoning was largely independent of GTK/GNOME and would apply equally well to Qt/KDE. Even the actual words on the page are mostly toolkit neutral. Think of it as a model-view situation (and lets just leave control out of the picture ;-). The real guidelines are a model, the existing GTK version is just a thin view layer. The actual work of modifying the guidelines to remove all GNOME reference and replacing that with KDE references is actually quite easy. I could convert a sample chapter, say, Windows or even Controls (which is very GTK heavy atm), if that would help KDE developers quickly evaluate the extent to which these guidelines could be applicable to KDE. As for the screenshots, I beg KDE developers to view them with their eyes closed, and apologize profusely in advance for the horribly ugly default GTK theme. :-) > 2: A mailing list is a good idea. freedesktop.org seems to me a good idea for > hosting it, IMHO. I prefer to see more input from other KDE developers on > this first, so please, take a breather until there is some consensus - I > can't speak for all of KDE. > > I think using the existing GNOME or KDE usability lists would either drown > current traffic in HIG concerns, or vice versa, the HIG traffic would be > smothered in desktop specific issues. FreeDesktop.org is fine. I could also offer the existing hig@gnome.org list (which is a small development list specifically for the HIG team) list, but people may feel more comfortable having the list on openly neutral ground. > 3: Someone makes a new list, in a week or so, and invites interested parties > to join, and we start there. Take the HIG one section at a time, clearly > demarcate what is different from KDE current best practise and/or diverges > from the written KDE styleguides, and bring those issues back to KDE for > discussion. I think this would leave a large majority of the document intact > exactly as it is, and will give a concrete list of changes for discussion by > KDE's developers and usability team. It would be fine to change the existing modus operandi of the HIG if people prefer. Our experience has been that *much* better results are achieved using a limited set of individuals rather than a general open invitation (which is what we use now). We tried to balance team composition (i.e. it wasn't all interface designers), but we also limited it to people with proven experience and dedication to usability. We are opening this up more in terms of access by the members of the GNOME usability list at the moment, but I'm sure many KDE people have shared my experience with needing a lot of filtering and cat herding to help less experienced usability-enthusiasts contribute productively. :-) I think your proposed process is good, though I would like to see some concentration on not just "syncing up" GNOME and KDE interfaces but actually moving to a future where we base our interface design off the same document (with specific extensions for each desktop of course). This means not just demarcating where KDE diverges, but figuring out where the HIG guidelines might need to be modified to be palatable for KDE. (that is not to say that I think we should modify the HIG to avoid necessitating any changes to KDE were it adopted....if the guidelines don't necessitate change, in some sense they aren't very useful guidelines at all, because you were already doing the best thing). For example though, some (but not all!) of the guidelines for icons are purely stylistic differences which should be removed from the HIG and seperate versions written for KDE and GNOME. WRT to large changes... I think its worth pointing out that KDE 3 is already closer to the HIG than GNOME 1.4 was. Despite what the introduction says about retaining a uniquely GNOME flavour, to a large extent there is almost nothing "GNOME-ish" about these guidelines. KDE 3 is actually more HIG-ish than GNOME 1.4 was. I think GNOME 2.0 (the first release where the guidelines had any effect) is somewhat closer to HIG compliance than KDE 3 would be, though even GNOME 2.0 has a looong way to go toward compliance. I guess what I'm trying to say is that adopting the HIG isn't "making KDE like GNOME" since the HIG is actually more similar to KDE than it was to the GNOME that existed when the HIG process began. A number of the HIG driven changes from GNOME 1.4 to GNOME 2.0 were actually from something like what KDE uses today to something we believe has better usability. Most of the larger changes that KDE would hypothetically make if it magically decided to adopt the HIG as-is are changes that GNOME also recently made in pursuit of better usability through design guidelines (or will make, for example dropping bordered frames in favour of a cleaner layout system). > Seth, please also note the timing: We're nearly ready to start serious > preparation for a release, the feature freeze is already in place, and the > message freeze is not too far away. KDE Developers will be fairly busy in > the next while, and changes to the code will be impossible for this period > too. All of this will be ready for discussion and or implementation (or not) > for KDE 3.2. I don't think there's a major emergency here. If we wait a couple months until KDE developers are able to give the problem better attention I think everyone is better off than if we do a poor job now. > speak. I expect I can be useful with the DocBook too :) yummy! -Seth _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-usability