Harvest + GSoC week 12

Well, I managed my last-minute merge request for Summer of Code 2010, and with that done it is time for my last GSoC 2010 blog post!

I am really glad I did this. It’s taught me a lot about myself (having never done a project in this fashion before) and I’m happy with how it turned out. GSoC was a nice change of pace and I hope to keep this up for a while!

(Hamster still says I’m a slacker. I need to convince it otherwise)

So, here are the results of some recent tinkering:

First, of course: new font! It requests the delightful UbuntuBeta font first and borrows some conventions from the Ubuntu Web guidelines.
Daniel added help text to the opportunity list filters. He gave each one a tooltip with a nice explanation.
There’s now a permalink for every source package, a nice Edit button for each opportunity, and some other small visual tweaks. Just little stuff like that.

Previously, every opportunity in Harvest had a text box labelled “Comment” that saved to a single database field. The idea was someone could fill it in with useful information for other Harvest users. It felt sort of like Launchpad’s Whiteboard feature in Blueprints.

I decided that implementation would encourage very complex comments. That’s a problem because Harvest aggregates other stuff. There’s a good chance whatever it links to will have its own comment system. I wanted to differentiate Harvest’s comments so they would never be seen as alternatives to whatever is in a referenced bug tracker. Instead, these should be, from top to bottom, specifically for small pointers.

So, we played with it and I added Notes (which is apparently the least commonly implemented synonym of Comments). Notes are little messages you can add to opportunities. Each note is basically a text field limited to 250 characters. No special formatting and no newlines. When I write one, I think of IRC.

The feature isn’t as quick to find as I’d like (there’s an app bug report for that), but it’ll be good to see how people use Harvest before adding more stuff. There are probably all sorts of cool things that could be done, so I’d love to know in the comments here if you have an idea!

(…And I can’t believe I haven’t done this yet)
Thank you to Daniel for being a great mentor! I can confirm the rumours are true: he is an excellent guy. I’ve really enjoyed working with him.

I didn’t quite get to everything I wanted for GSoC (and I have to admit I got carried away with design trivialities this week), but now we’re just a few small pieces away from a spectacular tool for Ubuntu developers. After a bit of a coding / remembering last year’s math course break, I’ll be back helping with some more of those bits. It’s going to be fun!

Here’s a completely unrelated bit of good news: I learned that UDS-N is now short for UDS-Natty, and I miraculously have no exams anywhere near late October ;)
So, assuming I can find a narwhal and convince it I am indeed smart and fashionable, I’m totally hoping to get there, meet people, learn lots of stuff and wax lyrical about Harvest, slideshows and release notes (as I do). Should be fun!

Harvest + GSoC week 9!

The past week, unfortunately, hasn’t been very productive for me. Still, I have a few things to show!

I did a bunch of cleanup (again) and I toyed with animations for a while. There is now an animation (and a loading indicator) when new results are retrieved for the filters. One philosophy I have found myself following is that this UI that never, ever blocks on a task. So, no matter what is happening, you should always be able to click the same buttons you could before.
(On a related note, I’ve been very excited about Blender lately).

Turns out non-modal design has an interesting impact as far as loading indicators are concerned. I wanted this indicator to be totally unobtrusive, but also obvious. So, as soon as someone starts adjusting filters, they can see that Harvest is waiting, then loading results.

It’s a little bubble that appears from the top of the results and is always visible at the top of the screen as the user scrolls. Conveniently enough, the existing results are all pushed away to make room for it. That was an accident at first, but really it makes the slide in a bit more pronounced and it means it doesn’t overlap anything you may have been looking at. (And even if it does, you can fix that by scrolling up).

Pretty simple :)

I made a quick video to show how this is all working:

The other thing I tried doing was to have the Javascript interface record its state in the location so it can be bookmarked and navigated through in the browser history (with the Back and Forward buttons).

I learned a lot of terrifying things, since I’ve never done that before.

Of course, the first terrifying thing is that you can’t change any part of the URL except the part after #, which never gets sent to the server. Well, you can change the other parts, but when you do it redirects to the given URL. That’s a good thing, but it does make life a little difficult for me :)

So, what we need to do is change location.hash to describe the current state, just like we do with the query strings sent to the server. There also needs to be an event handler watching for that change. With those two bits in place, that event handler is called whenever the user presses the Back button or loads the page from a bookmark, and it can apply the given state.

There are piles of jQuery plugins for this job. Two stood out above the pack: Asual’s impressively professional looking jQuery Address, and Ben Alman’s deliciously silly sounding jQuery BBQ. After some pondering and licking my lips, I went with jQuery BBQ.

BBQ is very clever in its simplicity. It uses the existing jQuery.param stuff to generate a query string the usual way, then it puts that in the hash part of the url instead of the ? part. It adds a “deparam” function to deserialize those query strings, a browser-agnostic hashchange event, a few helper functions, a bunch of documentation, and that’s it.

Unfortunately, even with jQuery BBQ, my work got really loopy here. In short, there are a lot of variables to deal with already and adding more almost exploded my brain.
(That was no doubt strengthened by a brief interlude at the family cottage, where I regressed to glorious redneckism and finally unlearned PHP)

So, unfortunately, I’m going to hold off on that for now. I could have planned the Javascript stuff much better, and getting BBQ working smoothly is likely a rewrite away. It may be a bad idea anyway. If someone shares a link that has #querystring instead of ?querystring, that link won’t work for anyone who has Javascript disabled. Instead, I’ll probably go the Google Maps approach, offering a “Permalink” button but never editing the URL in operation.

Next up: nicely formatted package details, and editing opportunities!

The borders: Cut them all down!! (Mockup)

I keep babbling about how ugly I think Appearance Preferences is, so I played with GIMP just now and made a couple of mockups.
I’m hoping to stay grounded in reality here.

First: the problem!

This here is the status quo in Gnome. The problem is not limited to Appearance Preferences, but it’s easy to demonstrate with it. I’m just going to focus on the Background section, too, but what I’m doing can be applied to the others. Let’s say I right clicked on my desktop and innocently selected “Change Desktop Background.”

The thing that immediately deserves a significant chunk of ire is that empty white patch to the right of the icon view. Were the window a few pixels wider, it wouldn’t be there. As it is, this gives us a 3×3 grid of tiny icons, with more space between the icons than the icons themselves, from which we need to choose a background picture. And that breaks one of my rules: Never, ever expect your user to resize a window.
We aren’t going to make the window wider, but we are going to fix that problem.

The next issue is visible by scanning across the window. I go through three heavy lines: the window border, the tab bar, and the frame around the icon view, before I get to the meat of this thing. That is three layers; three sections of the interface.
If this was a printed document, the icon view would be a subsection.
But what is this interface’s main objective? Choosing your background picture! Doesn’t that seem a little bit crazy?

My first mockup is getting rid of that excess border between the tab bar and the icon view…

This highlights a particular habit Gnome apps have, especially when they follow today’s HIG.  (And, as you might have guessed, I disagree with this habit). They add padding, padding, padding. They are obsessed with padding. Every container has 12 pixels of padding on every side.

Of course, I like padding, too. I want things to use padding. If everyone used padding and margins, maybe themes wouldn’t be using so many lines! (The other thing that makes me crazy, but it turns out these go together in our case. Note that one strangely thick border is now gone. I did cheat a bit by making it a 1px border instead of a 3px border, but as far as I can tell that’s a theme thing).

Unfortunately, padding is being used robotically to fill an arbitrary requirement. Everything uses the exact same amount of padding around every element regardless of what that element means. The result is a tangle. (See above).
I propose a slightly more organic approach: “Padding should be in multiples of x, never less than y pixels and never more than z pixels. In general, no control should reach within w pixels of a window’s edge or a heavy border.”

There is another problem here: if a container creates a heavy border, it is redundant to give the next container inside it a heavy border as well. Besides, having a sudden contrast between two halves of a double border defeats the purpose; it adds noise right in the middle of the attempt to create a clean surface. That can happen if one follows a mathematical guide to padding.

At this point the mockup is attainable with GTK as it is right now. However, I think I only applied my solution half-way. The icon view still has its own spacing around each icon. (Conveniently enough, it is precisely the same as the padding within a toplevel container: 12px). Here’s my attempt with that:

This one would need a few small changes in GTK, in themes and in philosophy.

The first thing is this interface stacks vertically, and only vertically. Trying to differentiate empty space from another element’s empty space going horizontally was a fruitless exercise, so this stops trying to do that.

If you draw a line down the left side, you will notice that the edge of the left-most icon in the icon view, the Style label and the Help button are all aligned. However, instead of a single Alignment, I’m adjusting each element on an individual basis to align based on its content.

As well, the buttons part of the Notebook widget would need a settable left margin. Quite attainable, really! There’s precedent in any web browser where the content spans to the edge of the screen. (MacOS’s design is interesting, too. Over there, a tab bar at the top of a window is styled a bit differently than one somewhere else).

I’m cheating a little by assuming that the theme will use a different background colour inside a frame or a notebook container. That is the case with Clearlooks or Elementary, for example. By varying the background colour, we can strongly communicate that the tabs at the top affect a particular thing without wasting 45,156px² of screen space on layers of margins and borders.

Harvest GSoC project: week 5!

The last two weeks of my Harvest project have gone really well. It isn’t flashy and exciting and earth-shattering (yet), but I’m happy with it.

First of all, my branch now has Packages and Opportunities filters. I implemented a bunch of each, and they are resolved in order. First Harvest runs the package filters, then it filters the opportunities that belong to those packages, then it hides packages that have no visible opportunities after all that filtering.

After a long period of me obsessively poking things, Daniel talked me into making a merge request for my branch (to lp:harvest). He and James W gave it some really thorough code review, which has been a huge help! Now it all feels tidier and a little more justified, so I can use the code I wrote without that constant temptation to rewrite it.

At this point, performance is much improved. Details are only shown for one package at a time, so the incredibly long waits (and self-destructs) have gone away.

In addition, the filter system consistently does 4 SQL queries no matter what is being searched for. Of course, that doesn’t say it’s running as well as it can, but it does mean the system is more orderly. It only hits the database once for each type of data. (One query for package sets, one for opportunity lists, one for relevant source packages, one for relevant opportunities). This puts more thorough optimization within reach.

Rather than trying to optimizing things for eternity, I’m off to something completely different for now: fancy Javascript to load new content in line with the page! The idea is a big query will still have a visible wait (always will!), but a complete page won’t need to be created each time; just the specific results, with a nice spinner while they’re loaded. Less jumping around, quicker and more fun.

For the first step, I have to admit I got a little carried away and started redoing the base template from scratch. (It should save me some time, really. The Javascript will be attached to some kind of DOM tree and I don’t want to fiddle with that twice). Still an early WIP, but I think this looks quite pretty :)

I am starting with a prototype written in straight HTML; no Django template markup yet. It’s helping me straighten my thoughts for how the filters’ render() functions should link together. The interface is taller than I would like, so I will need to do something to collapse the Choice filters when they aren’t being used. Oh, and we don’t seem to have a logo. Still, the gist of it is there.

Next for me is figuring out YUI and making that filter interface on the left interactive. Really exciting! Javascript toolkits are amazingly fun to use.

Speaking of web design, I decided I didn’t like my nearly-stock Blogger template anymore so I spent way too long redesigning it (while cursing Blogger for being an awful platform to make templates with). What do you think?

Yet another reason why menu bars are evil

Seif Lotfy posted excitedly about Ian Cylkowski’s in-depth Nautilus redesign mockup.

I found it very nice and refreshing, too. However, I noticed one strange thing: the menu bar just up and vanished. Ian`s incentive intrigued me:

Hidden Menubar: I’m not going to take sides here on whether we should still be having a menubar in applications or not; it’s another minefield of opinions and flaming. I’m personally fine with a menubar inside the application, but I also happily use applications that tuck away the menubar under a single icon (think Google Chrome). But I do think that we should have the option here. In my mockup, all the menubar settings can be brought up with the settings icon (first icon after the pathbar). But if you would like to see the menubar permanently then this, too, should be an option.

Being one of those people who considers the slightest growth of an options dialog a crushing defeat, I just have to debate that. Hopefully this won’t cause the flame-war Ian predicts. That would be a bad start for my first aggregated blog post. (Hi, Planet Ubuntu!)

What I would like to do is go over why Chromium’s menus are great, and why they absolutely are not just “tucked away under a single icon” but intentionally designed that way and inseparable from that particular approach. It’s about simplifying the menu so it relates to the two distinct subjects the user interacts with: the application and the current page.

There are millions of things I dislike about menu bars, but that would take all year to discuss. (And I have different things to fix). I’ll just vent about two problems which relate closely to each other:

  • They traditionally consume 100% width. A small menu bar looks wimpy. Half of that menu bar will inevitably be wasted space no matter how hard the developers try to cram stuff into there.
  • There is a strange urge to duplicate everyone else’s menus for consistency and have as many of these as possible. For some reason the uniqueness of an application is expected to vanish at the menu bar, which becomes an abstract world with words like “File” referring to web pages, photos, applications and video clips alike. Menu bars are popular things for accessibility, so I wonder if this abstraction helps in that regard or hinders.

Having said that, GNOME applications deserve some credit for usually replacing the title of the File menu with Music or Photos. Yet, the generic top-left-most menu is still there in spirit.

As we can see from the gnome-terminal screenshot, though, the File menu’s spirit is weak. Challenge of the day: name one file related thing there, then explain why adding and editing profiles should be in different places.

So, Chromium is interesting because it is one of few applications to finally take a bold step against the ’90s fashion in menu bars. First of all, the distinct lack of a menu bar clears up the interface considerably. There are still menus, however, because menus are important to categorize functionality in a pleasant fashion. Then they accept that, to an end user, the browser is not interacting with “files” but with web pages. So, the File menu becomes a Page menu. Completely. They also throw away all the baggage that the File menu used to have.
…and that is where the magic happens. Now the menu has a far more powerful, meaningful context. Actual useful functions can be put there that are of importance to people and relevant to what they are doing. Things like zooming, printing, copying and pasting inside pages.

The remaining stuff happens in the context of the Application menu (the wrench). Quitting, opening windows, changing preferences, dealing with bookmarks; anything that is related to the application as a whole, not the current page. Since Chromium was designed with a logical scope, that is everything else it does (except what extensions add).

I think we can do a lot better than the traditional menu bar. Just yanking it out, though, won’t do us much good.