Older blog entries for lucasr (starting at number 223)

Horizontal Space

Bastien’s latest post about the new GNOME screen panel—which looks generally nice by the way—reminded me of something that bugs me a bit on certain user interfaces with abundance of horizontal space.

In the new screen panel case, the brightness slider widget fills most of the window width. My first impression was “Wow, I’ll have to drag the pointer quite a long distance to adjust brightness”. But this kind of misuse of horizontal space is not so rare in other contexts. You can also see it on MeeGo’s status panel with too wide buttons on top. Or in some Maemo 5 apps, with weird menu buttons filling the whole screen width.

This kind of issue usually happens when the UI has to conform with some broader constraints from the design. For example, the screen panel runs inside GNOME’s System Settings which requires all settings panels to have the same dimensions. MeeGo’s status panel could definitely be less wide but the design seems to require all panels to fill the screen width. All that for good consistency reasons. But you might end up giving more space then the UI actually needs—in which case you probably want to ensure nothing looks odd.

Bad use of horizontal space can be avoided by spending a bit more time getting your UI layout right for the available horizontal space. Adding inconsistency to better cover special cases might be acceptable—if the resulting UI doesn’t have a major negative impact on the user experience.

The examples I gave here are not the end of the world or anything. But they definitely add some unwanted awkwardness to the UI. And, you know, little details matter.

Syndicated 2011-02-16 17:59:00 from lucasr.at.mundo

Animate Wisely

I’ve been hacking on rich UIs with animations for a few years—both in the litl OS and in my pet project. There was a time, not too long ago, that doing animations in your web, mobile or desktop app was not so common or convenient to do. You had to mess with weird lower-level APIs or write a lot of cryptic ad hoc code. We just didn’t have nice high-level APIs for animations.

Nowadays fluid UIs with animations are relatively easy to do on pretty much all major platforms out there—jQuery, Clutter, Core Animation, WPF, QML, Tweener, etc. Things like fading, sliding, zooming, rotating, scaling are all just a few of lines of code away. So it’s very easy to fall on the trap of overusing animations just for the sake of eye-candiness. But animations can have a very negative impact on the user experience if not done properly.

Delayed interaction. Using UI animations often means that you’re making your app take more time to go from state A to B. For example, by using this ribbon-like effect on modal dialogs—motion mockup by Jakub Steiner—instead of just popping them up immediately, you’re adding a delay between the user request and the dialog being ready for interaction. The animation in this case is not a bad idea as it helps the user understand the UI and it’s fast enough. But if you consistently delay interaction with animations for no good reason, the UI quickly gets very annoying to use. So, getting the timing of your animations right is very important.

Distraction. When animations are not subtle enough, they cause users to move their attention from the current task to the animation itself. It’s like the UI is saying “Look! I’m animating now!”. Google’s particle similator logo is an extreme example of a distracting animation. Every time you add an animation just because you can or because it’s “cool”, you’re probably just distracting your users.

Confusion. Animations might actually confuse users. One recent example is the Twitter for Mac’s continuous slide out transitions that create a strange sensation of infinite “stacking”. Confusing animations might seed wrong assumptions and uncertainty about how the UI works: “Why does it slide to right again when I click on the previous tab? Am I doing something wrong?”.

Repetition. Certain animations look cool on the first few times you see them but become quite annoying later on. The repetition problem is aggravated when the repetitive animation is also confusing, distracting or delays interaction. For example, the tooltips animation in MeeGo’s Netbook UX is both repetitive and distracting—Intel guys are aware of this issue. Commonly used UI elements should have very subtle or no animations at all.

And I guess there are many other ways animations are just done wrong. Bottom line is: with all the simple ways of filling your UI with all types of animations these days, it’s quite easy to end up overusing them. Resist the temptation! Animations work best when they highlight the underlying mental model of your software and improve UX. Animate wisely.

Syndicated 2011-02-04 23:42:56 from lucasr.at.mundo

The Board 0.1.1

Here we go again. About a month ago, I made the first-ever release of The Board. Now it’s time to roll a new release with some pretty nice features and bug fixes. So, what’s new in The Board 0.1.1?

• Sound elements with Voice Memo support
• Select, move, align, distribute, and remove multiple elements
• Five brand-new page backgrounds

It also has a couple of important bug fixes such as 637703 and 637484. Just like 0.1.0, this is not a release for end-users. The Board is currently unstable, buggy, and often loses data. Early testers are more than welcome though—to provide general feedback and report bugs. Distro packages for 3 popular distros (Ubuntu, Fedora, and openSUSE) are coming soon—I will announce them in my blog, don’t worry. That should help early testers get started easily.

Versioning. I decided to use the classic odd-unstable/even-stable style of versioning. This is a common practice in GNOME and should be natural for most contributors in the community. In terms of milestones, this means that you’ll see a bunch of 0.1.x development releases from now on and 0.2.0 will be the first release for end-users. I honestly have no final answer as to when 0.2.0 is going to happen yet.

What’s next. I will be rolling a new development release (0.1.2) in the next few weeks—depends on the amount of spare I end up having. I’ll focus on two things: toolbars and element stacking. I’ll do a second design iteration on the toolbars with focus on scalability. In practice, this means fixing bugs like 636637 and 636634. Element stacking is the final major feature for multiple elements which I ended up moving to 0.1.2. You’ll be able to create stacks of elements in the page. I’m quite excited about this one!

Syndicated 2011-02-01 17:33:51 from lucasr.at.mundo

Micro Commits

It’s been a few years since I became a full-time git user both at work and in the FLOSS projects I contribute to. I guess there’s no need to argue in favour of git at this point as it has become a sort of given on any sane software project—along with some other DVCS. I can’t really remember anymore how my life with Subversion was. Sad, I guess…

One of my favourite cultural shifts in software development brought by DVCS is the use of micro commits. JP has just blogged about it. Here are what I consider the most useful benefits of micro commits.

Tell a story. When you send one huge patch implementing a feature or fixing a bug, you’re completely hiding the incremental process through which you reached your final solution. On the other hand, a well written series of micro commits tell the reviewers the whole story of your code changes, step by step.

Discipline. If you want to tell a coherent story with your commits, you obviously need to organize them properly. Each commit should be a self-contained step towards the new feature or bug fix. Writing good patch series requires quite a bit of practice. It’s a very good exercise in terms of splitting a complex solution into a well-defined sequence of code changes—leading to more disciplined development practices.

Better code reviews. Because micro commits are, well, small, they are much easier to review because they do only one thing at a time. You get better code reviews as a consequence because the patches tend to contain no unrelated code changes.

Bisect and cherry-pick. Huge commits makes bisect and cherry-pick close to useless. And you don’t want that! Micro commits make it much easier to spot what caused a regression. Plus, they make it very easy to cherry-pick commits from one branch to another.

Git makes it utterly simple to move, split, squash, reorder, and remove commits providing the best ways to write good series of micro commits. It allows you to look like the perfect developer to the outside world by incrementally fixing your commits before submitting your patches for review. If you’re not micro-committing yet, you should.

Syndicated 2011-01-29 02:47:34 from lucasr.at.mundo

Selection in The Board

Since I started dogfooding The Board on a daily basis, it became clear to me that not having a simple way to arrange multiple elements in the page is quite annoying. If you wanted to arrange multiple elements in a specific area of the page, you’d end up having to move each element separately, one by one. Argh! This is why I decided to focus on an initial set of features targeting this specific issue for the upcoming release.

You can now select, move, align, distribute, and remove multiple elements in a page. Click on the image above to see a video demonstrating the new features. Selection can done in three ways: the usual dragging from background to start selecting a region of the page, Ctrl+clicking on elements, or using Ctrl+A to select all elements in the page.

Once more than one element is selected, a context toolbar slides in presenting all available operations for the selection. I’m following the same obviousness, clarity, and consistency principles I’ve discussed before. The available operations for any app state are always visible and easily accessible. No need to dig around to find out what to do.

As usual, feedback on the design decisions are more than welcome. So, what’s next? I’ll be fixing a few critical bugs and then roll a new release. I’ve been pestering distro guys to create packages for The Board. I’ll hopefully be announcing the next release with links to distro packages.

Syndicated 2011-01-26 02:30:23 from lucasr.at.mundo

Backgrounds in The Board

When I started writing The Board, I was quite pragmatic about the appearance of the app. I used my limited Gimp and Inkscape skills to produce the UI theme images and grabbed some free background images from internet.

So, the background images you’ve been seeing on previous The Board demos are just placeholders. Christian Ankert suggested—on the respective bug report— to use some of the free stock images by Kimberly Crick. Great tip! I produced five beautiful backgrounds based on her stock images: cork, cardboard, green, paper, and fabric. The goal with those backgrounds is to reinforce the physical aspect of the UI. Hence the use of textures mimicking real-world materials instead of abstract stuff.

The UI still needs some love from a real graphic designer but I’m quite happy with this initial set of backgrounds. If you want to propose new ones, please submit them to GNOME Bugzilla.

Syndicated 2011-01-14 15:02:07 from lucasr.at.mundo

Sounds in The Board

So, The Board 0.1.0 was released a couple weeks ago with a good set of initial features. The 0.2.0 release will come with a couple of interesting new features. Here’s one of them: sound elements with voice recording capability.

At this point, it should be clear that The Board is all about easily making daily records in form of videos, photos, notes, and labels. The addition of sound elements is natural step. Click on the image above to see a video demonstrating the new feature.

So far, voice recording in GNOME has been an obscure feature because the sound recorder app is not easily accessible and it doesn’t provide a convenient way to organize and access your voice memos. The Board makes it extremely simple to record voice memos. No need to care about saving files or anything. You can easily label your tapes for later reference. Just add a sound element and start recording!

The design still needs a bit more polishing of course—show playback and recording time, improve tape animation, error messages, etc. Feedback is welcome as usual. If you want to try this and other features, just follow the instructions on the hacking page to get The Board built and running on your system.

The next feature I’ll be working on is actions on multiple elements. Operations like removing multiple elements at once, aligning and distributing elements on a page, stacking elements, etc. Some exciting stuff coming soon!

Syndicated 2011-01-10 23:40:31 from lucasr.at.mundo

The Board 0.1.0

Today I’m officially joining the GNOME Old Farts Club. I thought it would be a good time to make the first release of The Board. Ladies and gentlemen, I give you The Board 0.1.0! I wanted to do this a few weeks ago but with so many moving parts in our platform it was actually a bit hard to reach a point where all dependencies were actually working fine together. So, what is this release about?

Feedback. First of all, this is not a release for users. The Board is buggy, unstable, and lacking features at the moment. But it’s in a dogfoodable state for developers and expert Linux users. Current feature list includes:

• Add, load, remove pages
• Photo, video, note and label elements
• Add, edit, remove, resize elements in a page
• Basic Firefox and Chrome extensions
• Basic Nautilus extension

I’m expecting to get some useful feedback from early testers and developers on those features and the general UX. You can get an idea of what’s in the release by having a look at the previous blog posts and respective videos listed in The Board’s wiki page.

Contributors. If you’re a developer interested in setting up a development environment to start hacking on The Board, have a look at the hacking page. I wrote a script—heavily based on what GNOME Shell provides—that automates most of the process of fetching and building dependencies from git. Please report any build problems on GNOME Bugzilla. I filed bug reports for quite a few known bugs and missing features that should be a good source for initial contributions.

Distros. Even though building The Board and its dependencies became much easier with the above-mentioned script, it’s might still be a bit painful to get The Board running on your system. So, here’s a call for distro packagers to create easy-to-install packages to be used by early testers. The idea is to be able to provide the simplest possible way to get The Board running on all major Linux distros.

So, what’s next? I’ll continue to fix bugs and hopefully make a 0.2.0 release soon with a couple of new features: audio elements with voice recording capability and support for actions—align, distribute, remove, etc—on multiple elements in a page. I expect to be doing more frequent releases from now on.

Syndicated 2010-12-23 23:00:51 from lucasr.at.mundo

Adding to The Board

When I first introduced The Board, I generally described how I envisioned things being added to the pages—have a look at the “Add to The Board” and “Integration with other apps” sections in the intro post. I decided to spend some time implementing a few interesting ways of adding content to The Board so that the app concept gets a bit more clear in practical terms. Click on the image above to see a video demonstrating all features described here. Here’s the user story I have in mind:

Henry is a journalist who writes gadgets reviews. He was assigned to write a review of this new Android phone. He needs to do a bit of research before starting to write. He activates The Board and creates a new page called “Android article”.

He opens the web browser to search for reviews, pages, images, and videos about the product. For each relevant page, image, video or piece of text he finds useful for his article, he simply right-clicks on them and adds them directly to The Board.

He also has a few local documents about competing products which might be a good source for his article. He opens some of those documents, copies the related pieces of text, activates The Board, and pastes them as notes.

He then remembers he had already downloaded a few photos of the phone a few days ago. He opens Nautilus to access the folder containing the images, right-clicks on the images and adds them to The Board as well. He activates The Board again, presses ‘t’ to add a new note, a quickly writes down a few ideas on how the article can be structured.

Henry is now ready to start writing his article.

Browser. I’ve implemented extensions for Chrome and Firefox. The Chrome extension can only add links and text selections as I couldn’t find a good way to handle photo and video downloads—I hope to get this implemented soon. The Firefox extension is more complete and allows you add links, text selections, images, and videos (using HTML’s video tag, not flash) from the browser.

These extensions add a context menu item when right-clicking on the cited web content. In case of images and videos, they automatically download the file to a proper user directory before adding a respective element on The Board’s current page. The extensions communicate with The Board via HTTP. A notification is shown when content is successfully added.

One big missing feature is a toolbar button which intelligently adds the current page to The Board. This means that if you’re in, say, Google Maps, if you hit this toolbar button, it adds the map to The Board. If you hit this button while viewing a photo on Flickr, the photo itself is added to The Board. You got the idea.

File Manager. The Board’s integration with Nautilus is done through an extension. The extension adds a context menu item every time the files can be added to The Board. For now, it only allows adding images. Videos should be coming soon. A notification is also shown when content is successfully added from Nautilus. This was the first time I wrote code based on the new GDBus API. Pretty simple to use.

Clipboard. I added some initial code to handle paste command on The Board’s window. In practice, this means that if you copy text from somewhere, you can just use the usual Ctrl+V keyboard shortcut on The Board to paste it as a label or note. Still need to implement URI and image pasting.

Keyboard shortcuts. It should be simple and fast to add things to The Board while using it directly. The current keyboard shortcuts are ‘l’ for label, ‘t’ for note, ‘p’ for photo, and ‘v’ for video. When something is added to the current page, the new element is activated straight away and you can start typing even before it reaches its final position.

This is all very initial code. It’s definitely a bit buggy and missing features. But it’s in a dogfoodable state—for developers at least. In fact, I’ve been dogfooding The Board full time for a few weeks now. I added this temporary status icon that shows and hides The Board’s main window—you can see it in the video. Works well enough for daily usage.

I still haven’t decided how to integrate The Board with GNOME Shell yet. That means figuring out how the “activate The Board” part of the user story above would actually happen. I’ve been playing with some mockups but nothing solid came up so far. Ideas—especially from GNOME Shell guys—are welcome. Patches for all the missing stuff I mentioned above—or for anything else really—are more than welcome too.

Syndicated 2010-12-06 01:40:48 from lucasr.at.mundo

Running Uninstalled

Back in 2008, when we started writing the initial infrastructure for the litl OS UI, Havoc added a way to run the whole thing using uninstalled files in the source tree. Back then, I was so blindly used to the “make → make install → run” cycles that I didn’t think this would be especially useful. I was obviously wrong.

litl’s UI shell is a relatively big component comprising our window and compositing manager, UI shell, plugin framework, a few highly integrated apps—online photos, video chat, settings, friends, etc—among other things. Having to install all that for every change in the code would be time consuming and utterly distracting.

I added support for uninstalled run in The Board a few weeks ago. It’s an separate executable that allows you to run the app using fonts, images, icons, plugins residing in the source tree. The only missing part is being able to use uninstalled translations from the source tree—any good ideas on how to do it? GNOME Shell also allows you to run it from source tree inside Xephyr using a wrapper script.

The bottom line is: any step between a code change and running the software is a distraction. If you can make your app run using only uninstalled files from source tree, do it! This is especially important in complex code bases using lots of different assets—icons, images, UI definition files, translations, fonts, etc. This allows you to test your code changes without much hassle. And it saves you precious time.

Syndicated 2010-12-02 22:47:37 from lucasr.at.mundo