It seems you can’t turn anywhere today without some mobile app hitting you over the head. As it became so common and used everyday, it’s definitely time to continue a well known series and to see how to create one.

Idea

Ideas are many and they can come from different sources. It can be a client’s idea or yours. You can extend your own products or services with a new media (mobile weather forecast) or build it from scratch as a stand alone version (calculator).

How to generate an idea is a theme for another post, but it’s very important to have one. And not just a vague idea – you should have a very specific and strong vision of what it would do and how. Otherwise it’s just playing with your mobile device. It can be fun for you, but not very useful for others.

Mock-ups

This is where the hard work starts. As soon as you have decided on an idea, it’s time to create something. The path to a finished application is very long and hard. It gets worse towards the end so it’s better to make most of the mistakes early on. Design and coding are hard and expensive, sketching is not.

Why mock-ups? Because it’s important to define all use-cases, user interactions, application structure and layout up-front. This way you’ll find out many things you didn’t think of. Some are not intuitive, others overly complex. When you draw ALL the screens and actions, you’ll probably find out it’s more than you predicted, so it also helps time and work organization.

Paper mock-ups are great because they are very quick for small projects; paper cuts can be touched, rotated and easily rearranged, and you can easily write quick notes on the back of it while sitting in the park (no electricity needed:).

Mock-ups creation is usually accompanied by many brainstorming sessions. If you have a team working on this, it’s good to involve all team members (or at least the leads if it’s too big), especially designers and developers. They are often looking in different directions and the gap can be to big to overcome later. By creating the mock-ups together you can be relatively sure they’re on the same page. Designers will draw all the features needed and won’t try something that’s not humanly possible. Developers will understand why the homepage has to look like that and won’t miss out the fancy window sliding or some transparency effect.

Tools for sketching are many and there isn’t the best one. You’ll probably want to start with something very quick and you can’t beat the pencil and paper or whiteboard. Some later sketching can involve digital tools; classic drawing tools (Photoshop/GIMP, Illustrator/Inkscape) or specialized tools for creating dynamic mock-ups (Balsamiq Mockups, Mockingbird).

Prototype

Involve users early. Is there a better way of doing that than giving them something to play with? Prototypes serve two purposes.

Get feedback from testers and potential users

Mock-ups are great, but you created them and you knew what you wanted to do with the mobile application. Try giving it to a group of random bystanders and see if they understand what that icon in the upper left corner does.

Try some new technical capabilities and discover possible constraints

Not sure if that real-time GPS tracking will work? Try it out as soon as possible to avoid catastrophe further down the road.

Developing a prototype can be time-consuming, but there are ways to cheat and get great results. If you need feedback for the user interface, tools like Flowella can be of great help. It frees you of writing code (so even designers can use it) and you can reuse scanned hand drawn or digitally made sketches. That way you can create a prototype really early and test your decisions and assumptions.

Design

Most developers don’t like to admit it (or even say it out loud), but design is the most important thing for the final user. Design is more than just pretty pictures. It’s the intuitive layout and navigation, data presentation and general usability. They all combine to a very popular term used today – user experience. Some of the problems will be solved during sketching and prototyping, so this is the time to finish it and add some polish.

The time of tiny gray forms on business PDAs is long gone. Your application needs to be beautiful to stand out from the crowd and useful to engage users in everyday use.

Resources are many and you will probably conform to the guidelines of the platform you’re developing for. There is one general rule though that will apply everywhere. As some hi-end mobile screens have the resolution almost as a regular screen, but the diagonal is four to six times smaller, be sure to regularly zoom out in your graphic editor and check that text is legible or button big enough to press with a thumb. The most common mistake of the inexperienced mobile designer is to try to put too much small things on the screen at once.

Both the mobile web and mobile application have the same information, but there is no question which one is more enjoyable to use.

Coding

If brainstorming, prototyping new technologies and early testing were done right, most of the problems are conceptually solved by now so coding should be straightforward. That doesn’t mean easy. It is still very complex and hard work, made harder by the fact that the time alloted for it is probably half of what is needed.

Platforms fragmentation and many different devices and vendors can only add to the list of things that can go wrong. Setting up a good development environment can be quite costly in some cases.

Testing

This step is often neglected, but is of vital importance. If you’re a big company, employ testers. If you’re running a small business or are only one person strong, give the mobile application to your friends and family. There is no way you’ve built such a complex product without any errors. It is better that your spouse finds out that the Share button doesn’t work than 10 000 people at once.

Publishing

Now, when it’s all over – know that it’s not. Unless you are distributing the application on your own terms (or building it just for yourself), popular mobile stores are probably the only option to reach millions of potential users. Publishing to application stores requires some technical knowledge (to prepare the installation procedure). It also requires patience because the Quality Assurance process can last from a week to more than a month if they find problems in your application.

When approved, it’s time to congratulate your team and yourself. Building a good mobile application is time-consuming and complicated, but when you see it downloaded and used, you know it was worth it.

It has been two months since the last decent post on this blog. We’ll try hard not to do that again. All we can say in our defense is that we were working on the Symbian mobile application for our weather service and some other projects (check the references). The mobile app is almost done and you can view what the fuss is all about on a short, but visually descriptive presentation.

If you’re interested in about finding out more about the app and be notified when it’s published, be sure to visit its page and leave an email.

Header photo credits.

If you are a Kad će Kiša user, you could be interested in some Kad će Kiša wallpapers. There are two flavors in three standard desktop screen ratios: 4:3, 5:4, 16:9.

Smooth and clean

• 1024 x 768
• 1280 x 1024
• 1920 x 1080

Grunge

• 1024 x 768
• 1280 x 1024
• 1920 x 1080

Credit for the grunge texture goes to the Dyrk.Wyst.

1. Bug fixes
2. New transition triggers
3. Export to Qt Quick

Bug fixes

A developer/designer tool can have all the features in the world, but if you can’t save and later continue your hard work the tool will be discarded very soon. Earlier version of Flowella sometimes had trouble saving your current progress. The workflow could be messed up after loading or the connections between frames could be lost – very frustrating. The new version doesn’t have any of those problems. Saving, loading and exporting works as expected.

New transition triggers

The old way to go to the next screen was to click on the specified area. Although this was sufficient for basic testing, it doesn’t really reflect the way people use mobile phones. New Flowella adds more triggers.

The first new triggers is accelerometer. The prototype can now respond to multiple motions. Just drag the arrow on the right side to the target screen.

The second new trigger. It is great for rudimentary animation and non-interruptible actions (updating, authorizing, etc).

Export to Qt Quick

Beside exporting to WRT and Flash Lite, you can now export to Qt Quick. Qt Quick is the new feature of Qt 4.7 and it allows you to create UI layout and behavior by using a language based on JavaScript. No C++, at least for the not-too-complicated stuff. If you’re familiar with web technologies, you’ll get around very quickly.

Here is the sample of the QML code generated by Flowella for one of the screens. It looks almost the same as the JavaScript object literal.

import Qt 4.7

Item {
   property string jumpToNode: ""
   signal jumpTo
   id: node
   focus: true
   Image {
      source: "Screenshot-20100930-165711.png"
   }
   Timer {
      id: timerTrigger
      interval: 500 /* Note: intervals must be > 0 for the timer to work */
      running: true
      repeat: false
      onTriggered: {
         jumpToNode = "3E579516-E275-5DF8-9AFE-99E9A6FC66B9.qml"
         node.jumpTo()
      }
   }
}

Paul Graham raises an interesting point in his post about the top idea on ones mind. He also ties it up nicely with the ever present issue of money and startups. A must read if you ever plan on raising funds for your business.

The following posts are all from Spencer Fry’s site. At the core of your startup there has to be an idea you’re in love with. When you have that kind of base, it is a lot easier coming up with the motivation and energy needed at the beginning phases when the going is tough.

So how do you start? The post discusses some of the key issues when starting your fledgling company. The idea of bootstrapping has been around since the first startup ever and is one every entrepreneur should be at least familiar with. A really great resource.

Another concept indispensible for the business owners is networking. This is especially important for the developer startups because that (and a related concept: marketing ) is almost always the most difficult concept for them.

And for some sweets at the very end. Something for all you non-technicals in a developer companies. It paints a superb image about the countless stuff needed to run any startup (even a developer based). So, yes, there’s room for everyone.

This list is, of course, ever growing so don’t be shy about adding your suggestions.

If you’re designing or prototyping an application for Nokia N900, this resource could be very helpful. N900frame_template.zip contains a SVG file with a N900 background (just like in the header photo), a status bar and a 800x480px workspace so you can easily export your work in native screen size and test it in one of available prototyping tools (like Flowella).

The frame was created in Inkscape, but you can easily import it in some other vector drawing program (AI, CorelDRAW) or use raster graphics in the bundle (N900 hardware and status bar pictures) in Photoshop or GIMP. All the sizes are pixel perfect so you can use it to create quick mock-ups or the final design.

The SVG file contains layers with normal and full-screen grids that are helpful for quick prototyping. Status bar can be easily removed so the full screen canvas awaits you.

1. First, you can’t miss the full screen background image. It’s targeted for the wide screen, but scales gracefully for regular 4:3 or 5:4 screens. No matter how big or small your screen is, there will be no holes – picture is “full screen” in all cases. And it’s all CSS.
2. The user interface is done in HTML5 and JavaScript (jQuery) and relies heavily on modern trends and features. The forecast is visible when JavaScript is disabled because it is the main information on the site, but complementary content and effects are not available.
3. There is one particular problem with the first two points – they don’t work in Internet Explorer 6 as expected, so we have decided that we will not support it in this project any more. If you go to the site with IE6 (as some people already have), you’ll get a blank page with a short description why and where to install new and modern browsers. It’s time to move on and leave it to the past.
4. The server side was created with Python and Django. It is our first Python web project, trying something new beside PHP and ASP.NET.

The site is far from over. It needs some front-end improvements and new back-end features, and we’re working on them. But it’s a good feeling to deliver something new and receive some quality feedback.

• Part 1 – why and how
• Part 2 – setup and examples (this one)

Installation

We’ll be using Mercurial. It is a distributed system, pretty simple to use and very convenient for the task at hand. You can download and install it from an official web page. It is available for the OS X, Windows and different *nix systems. You will install command line tool and we will use it here to focus on the meaning of the action, not on the tool’s interface, but for regular work you can download a TortoiseHG (visual interface) that will help you navigate and maintain the repository.

Basic commands

After the installation is finished, go to your terminal (command prompt on Windows) and write:

$ hg

You will get a Mercurial Distributed SCM title and a list of common commands. You can get a list of all the commands with the hg help command. OK, everything’s working so let’s get to work. Navigate to a folder where you want to start a new project or put an existing one under a version control. When there, type:

$ hg init

At first glance nothing happens, but if you look closely you’ll see we’ve got a new .hg folder. That’s our local repository where all the revisions are kept. Everything else is a working copy.

We’ll add a file to the folder to work with (or you can use existing files if you have them). I’ll use sphere.svg, but any file(type) you can edit will do. I have drawn an orange circle inside the sphere.svg. Now type:

$ hg status

We’ve got this:

? sphere.svg

It means the file is not under version control. Type:

$ hg add sphere.svg

Now the hg status (or hg st) will show:

A sphere.svg

That means the file has been added to the version control and that will be saved to the repository on our next commit. Let’s do that now:

$ hg commit -u YourName -m "Our sphere is still only an orange circle."

If you type hg log in the terminal you’ll see a history of the project starting to appear.

Whew! We’ve done it. Our first commit and one of the actions you hang around most. I must congratulate you. It’s not easy if you do it for the first time. But be assured, when you finally get it, you’ll be wondering how you ever managed without it.

Let us do another iteration of change and commit and than we’ll have a bigger picture of what we’ve done. Let us add a gradient on the sphere and commit.

$ hg commit -u YourName -m "A nice gradient."

If we would type hg log and make a pretty picture of what it said, this is what it would look like.

But what does it all mean?

It means you have a documented history of all the changes you’ve made. Better yet, with the update command you can go back in time and load any state in the working copy and review it. A repository is also a backup protecting you from any creative process (madness) that could ruin what you did earlier. If we would change something on our sphere and then some more and some more and it would finally look like a blue triangle. If we decided that it’s not what we want, we can very easily return to our latest state (last commit) with:

$ hg revert sphere.svg

More basic commands and a real-life example

Let us call John and Amy for help. John was also working on an orange sphere but he wants to improve it. He doesn’t have enough time because he has to work on other files in the project so he would like Amy to help. Amy agrees but would like to see how the sphere came to life so she could gather some more inspiration. The best way to do this would be to clone the whole repository. That way Amy would not interfere with John’s work and would have a complete history for reviewing. John types:

$ cd ..
$ hg clone project_John/ project_Amy/

Amy takes her repository and starts working. She makes two changes on sphere.svg and commits after each one.

$ hg commit -u Amy -m "Added some shadows to the sphere."
$ hg commit -u Amy -m "Gloss effect for the final touch."

John’s and Amy’s repositories now look like this.

If John is satisfied he’ll want to take in Amy’s changes. He’ll need to pull them and update his working copy to the latest change. He navigates to his project folder and types:

$ hg pull path_to_Amys_repository
$ hg update

In that moment the repositories are synced as explained in Part 1.

Resources and closing remarks

In these two parts we have laid a ground for some basic usage. A version control software is much more powerful and I encourage you to go through the Mercurial guide to find out more commands, use cases and workflows. Remove, rename, tag, push and rollback are some of the useful commands you should check out.

The workflow will be determined by your experience and the type of the project. Here are some notes I have found helpful when using a version control system for a design.

• Use clone repositories for testing, new features or some other work you’re not sure will end up in the final product. If it’s good, you’ll push the changes back to the original repository, and if not, the original one was not disturbed. Extra clone costs you nothing, messed up original work and a repository can cost you … well, a lot.
• Commit often. When you commit you don’t have to worry about the direction you’ll take next. If you mess up, revert.
• When having a more complex project consisting of multiple file types that need to interact to get a final product I always have a Screenshots directory. I create snapshots (in PNG) of the changed work inside (ex. website homepage). That way I can update to an earlier revision and quickly scan the screenshot to see the state of the work.

This will actually be a mini-series of posts. I tried to put everything at once but failed miserably These are the series’ parts published till now:

1. The basics (this one)

The heart of the alarm framework is the alarmd daemon which is responsible for doing stuff at specific times. Basically, we can tell it to raise a system alarm, execute a shell command on our behalf or make a D-Bus method invocation. The raising of system alarm entails displaying the standard Maemo system alarm UI with the time of the alarm, some description and a few buttons so the user can aknowledge or snooze the alarm for example. Executing a shell command (this, of course, includes launching a program) is pretty self explanatory. Describing the D-Bus framework is way beyond the scope of this post so I will just refer you to the D-Bus documentation if you want to know more. Or you can also wait and see if I make a post about D-Bus in the future

Now that the big picture is a little clearer lets spend a few moments describing the nitty gritty before jumping in. The alarmd functionality is available using the C API via the libalarm maemo library. You already guess what we are going to do. We’ll just link with this library and use it’s API for playing with the alarms. On to code…

I’m presuming a standard Nokia Qt SDK installation and using Qt Creator as our IDE. Naturally, you’ll also need a test project (or a real one if you prefer ). First thing we need to do is tell qmake that we want to use the libalarm C library. We do this by adding the following lines into our project file:

maemo5 {
    QT += maemo5
    LIBS += -lalarm
}

This means that the two lines between the curly braces are taken into consideration only if we are building for the Maemo platform. The first line tells qmake that we want the standard Maemo Qt module (this is needed for every Maemo application we make). With the second line we announce that we want to link the libalarm library which resides on the standard library search path. If this last line contained a lot of gibberish to you fear not, everything will become clearer if you study the gcc linking documentation. If you want to know more about the whole library linking stuff take a look at the TLDP program libraray documentation, especially the shared libraries chapter.

Now we can write some alarm setting code:

// Header stuff...

#if defined(Q_WS_MAEMO_5)
#include
#endif

// Other code...

    alarm_event_t * event = 0;
    alarm_action_t * act = 0;

    // Setup
    event = alarm_event_create();
    // The application id field is needed for every alarm you set
    alarm_event_set_alarm_appid(event, "Alarm testing app");
    // Alarm description displayed when the alarm is triggered
    alarm_event_set_message(event, "The alarm message for the system UI");
    // Set the alarm time 30s form now
    event->alarm_time = time(0) + 30;

    // Acknowledge action
    act = alarm_event_add_actions(event, 1);
    alarm_action_set_label(act, "Stop");
    act->flags |= ALARM_ACTION_WHEN_RESPONDED;
    act->flags |= ALARM_ACTION_TYPE_NOP;

    // Snooze action
    act = alarm_event_add_actions(event, 1);
    alarm_action_set_label(act, "Snooze");
    act->flags |= ALARM_ACTION_WHEN_RESPONDED;
    act->flags |= ALARM_ACTION_TYPE_SNOOZE;

    // Pass the structure to the alarmd daemon
    alarmd_event_add(event);
    // Cleanup
    alarm_event_delete(event);
    act = 0;
    event = 0;

// More other code...

This is the most basic of the alarm examples. It simply sets an alarm to trigger 30 seconds from the time it was set. The standard Maemo alarm system UI will display the set message and will give the user two buttons, one to aknowledge the alarm (“Stop”) and the other to snooze the alarm by the standard specified system snooze time (“Snooze”) which is by default set to 10 minutes.

I think my time for this post is at the end so I’ll bid you a fond farewell. Next time we’ll complicate things up a little bit by setting our own snooze interval and executing custom commands when the alarm is triggered. So stay tuned.

Here’s the series TOC till now for your convenience:

1. The basics (this one)

This article analyzes designer’s needs and shows how he or she can use SCM to help organize its work files. The first part shows why it’s good to use version control systems, explains what types of those systems exist and how they work. In part 2 we’ll use one to set up a few workflows that could be good for design work.

• Part 1 – why and how (this one)
• Part 2 – setup and examples

Why

Designers asked if they use a SCM will usually supply a blank stare and ask “why?”. It is a valid question and one that deserves an answer.

Every designer has its own workflow but most of them (if they know what they are doing) save different versions of a long project. They copy and rename the main project folder or archive/compress it for future reference and for backup. After some time the folder can start to look like this:

project/
    project_current/
    project_releaseMay2010/
    project_goneB&W/
    ...
    project_wireframes/
    archive2009.zip

Every folder has some or all the files of the current version. It is hard to track what happened to a individual file over time. And what if you work on a file for some time and decided that you want to undo the last two days of editing because you are not pleased with the result? It makes it even more problematic if you don’t have a recent backup and the file from the most recent “archive” folder is from … well … May. AND that’s just ONE person working on a project. Add two more and you’ll probably have a few more mortal enemies in your life.

A simple knowledge of a SCM can save you all that trouble and that’s the main answer to the “why?” question.

There are many developer specific tools for SCM, but not so many design oriented. There are a few, like Timeline, Adobe Version Cue or Softimage Alienbrain, that solve specific problems (like PSD files and their comparison) or have enterprise capabilities. The prices will vary depending on the feature list – you can expect to pay from $50 to $100000 (yes, six digits) for some studio editions. They are good and as one guy said:

… they have to be and you’ll tell that yourselves even if they aren’t because otherwise you’ll be painfully aware that you have just lost your pension.

But is this really necessary for normal work? My opinion is that you can adapt the general SCM (free!) for your workflow to remove common problems. The tools mentioned above can be helpful, but its’ not a show stopper if you don’t have them. It is comforting to know that some of those tools are just a nice graphical interface to a general SCM (we will use here) that hides in the background.

Before we start with use cases and examples, let us see how a SCM works and in what flavors it can be found.

Basic introduction to version control systems

Two terms are very important to grasp early on – a repository and a working copy.

1. Repository is an archive of all the changes made in the past. In the earlier example, the repository would contain all the folders: project_current, project_releaseMay2010, project_goneB&W, etc.
2. Working copy is just a snapshot in time from the repository or, more common, the current files you’re working on. When you make some changes to the working copy and are satisfied with the result, you will want to commit those changes to the repository. I’ll explain it more later, so don’t worry if it’s not totally clear for now.

Here’s a picture showing the relationship between a repository and a working copy. Committing changes to a repository and updating a working copy to an earlier version of your work are two most common operations you’ll encounter.

There are two types of SCM – centralized and distributed. The differences will not matter much for a simple work by a solo designer, but if a team works on a project, those differences can be crucial.

1. In centralized systems there is one repository and multiple working copies that can be of different versions. Every team member updates his working copy from that central repository (usually a shared server). The most popular centralized SCM is Subversion.
2. In distributed systems the repository is bundled with every working copy. That way every team member can have a whole history locally. All distributed repositories are equals so usually the team leader declares that his repository is the main one, so he synchronizes the changes from others when some important work is done. Everyone can have as many repositories as he wants. The most popular distributed SCMs are Mercurial, Git and Bazaar.

As most designers are visually oriented, lets put that in pictures. We’ll have John and Amy working with both types of SCM.

Example workflow of John and Amy working with a centralized system.

Example workflow of John and Amy working with a distributed system.

We’ll finish here for now. In Part 2 we’ll look how to install and use a SCM. I’ll also show you some workflows I used for design work so you can go from there and create your own. Check out our RSS feed or follow me on Twitter to get notified when Part 2 comes out, add comment below or nudge me on Twitter if you want to see some specific questions answered.