Category: GNOME

As one of those people who complained about the HTML output of DocBook recently, it’s good to see Shaun kickstarting some progress on this.

I think my main concern with those mockups is the line length… in English, ten words is about the most you can fit on a line before reading speed slows down. This isn’t so much of an issue for stuff that turns up in help browsers, as the narrow width of the window naturally restricts this anyway, but it’s a problem for things like the HIG that are normally read in a web browser. I’ve tried to deal with this in the draft HIG’s stylesheet recently by indenting the body text from both sides of the page, which also makes it easier to pick out headers. (Example)

My main gripe with the HTML version of large DocBook documents, though, is the lack of a navigation sidebar. Things like the HIG are a pain in the bahookie to jump around, when every other major online styleguide (Mac, WIndows, Java) makes it simple.

Not a lot:

http://lists.osdl.org/pipermail/desktop_architects/2005-December/000395.html

Was looking for a painless utility to do regular incremental backups of a bunch of stuff on my Ubuntu box today, and ran across sbackup, which was sponsored by Google’s summer of code. The UI could do with a little polish, but it was dead easy to set up, and so far it looks like it’s just the job. (Might even have a go at getting it to work on OSX, as I’ve yet to find a free OSX utility that does what I want quite so easily.)

I fiddled around with the online appearance of the draft HIG a bit yesterday… basically created a CSS for it, to try and prettify the raw docbook->HTML output somewhat. Here’s an example of the old and new look.

It’s very much work in progress, as I’m kind of learning about stylesheets and docbook customisation as I’m going along, and there are a few obvious bugs and things I haven’t got to yet. But I hope you’ll already find it a bit easier to read… personally, I’m quite pleased with the tables 🙂

Hopefully we’ll be able to push out a HIG 2.2 release fairly soon, after which I’d like to see us do a bit of an overhaul on the whole document. IMHO it’s getting too big and wordy, and isn’t really laid out as helpfully as it might be. I’m thinking we might want to focus more on the types of UI that developers are actually trying to create (document editor, applet, desktop preference dialog etc.), rather than have them piece together the information from a chapters about windows, menus, and controls.

But at the end of the day, you’re the people who have to use it… let us know what you think!

From the Microsoft Office UI blog:

Q: What is “Send a Smile?”

A: There’s a general philosophy Microsoft has been embracing more and more in all of our beta products, which is that people should be able to send one-off comments as easily as possible, while they’re “in the moment.” Windows XP had a “Comments?” link in every dialog box that let you tell us if the dialog was stupid. Previous versions of Office had the same thing.

Send-a-Smile is a related tool that goes a bit further. Anywhere, anytime, someone can click a “smiley face” to tell us they like something or a “frowny face” to tell us they don’t like something. We get a lot of context (with the user’s permission of course), including a screenshot, sometimes a short movie of the last 30 seconds, related documents, etc. There’s another tool called the Office Feedback Tool (also known as “Ebert”) which does a similar thing but with Thumbs Up and Thumbs Down.

All of these tools work on the principal that if someone has to open a newsreader, log onto a newsgroup, type a long message, and send it, we’ll lose a lot of valuable feedback just due to complacency. The idea is to reduce the barrier to entry for sending comments so that we get more data from the “heat of the moment.”

And of course, we have all sorts of tools that help us sort an analyze the feedback on the back-end.

I really like even the simple “Comments?” idea, and it would be cool if GNOME could do something similar in its development releases. It would probably need some sort of toolkit support so it could be easily added to any window or dialog, and easily turned off for the final builds. And of course, the hard part would be analysing all that data. But from the user’s point of view, it would be pretty unobtrusive, and would probably capture that Kodak Moment a lot better than having to go and file a bug report. (Plus, of course, people don’t file bug reports about cool stuff that Just Worked.)