I bought a Samsung Nexus phone in September after almost 4 years of being a happy Nokia E65 user. I switched because I didn’t have an Android phone to test websites against and it would be stupid to buy something expensive just to lay on my table waiting for an occasional test.

A month of use is enough to get a solid impression, but not enough to really know a modern phone. Which is alright, since I don’t want to write a pro-cons review of Android. Better ones have already been written. I am more intrigued by what design hints about its creators and their environment. Hints, not tells, because I know Android’s authors even less than I do my phone, which is to say I don’t know them at all and could well be wrong. Enough of disclaimers and let’s proceed with this Sherlock-like conjecture.

Data roaming is something that ought to be common, but is usually an obscenely expensive luxury and it’s nice that Android lets you turn it off to prevent unexpected expenses. However home network may not be cheap or unlimited either and what I really liked about an otherwise severely limited email client on Nokia N900 is that you could set automatic email retrieval to proceed only when connected to WiFi. Alas there are no connection based settings for data syncing. So this feature was designed for countries where cheap-enough data connection is available to most or in expectation that this will soon be so.

Notifications are an important part of Android’s experience and are done well enough to inspire iPhone’s. They are also less important to me than Android believes they should be. Pull-down notification system was obviously built for a steady stream of messages and as such would benefit from a few more options. Like K9 mail’s quiet time during which it would not check for new messages (or just be silent if it gets them). I’d also love to be able to set a different volume based on type of messages. I care about (rare) text messages, but don’t want to be bothered with Twitter’s deluge. However if I wanted to be notified about everything as soon as it happens, then I would just love what I got. I know many social media users who surely do.

The under-appreciated side of Nokia has always been company’s understanding that mobile users around world are not same. Android however doesn’t care about subtleties. E.g. selecting language of your interface will also select when week starts (is it Monday or Sunday?). This would be a great shortcut for setting locale in one swoop, but is incredibly annoying when you want/need to override it.

None of my examples is actually a bug or even necessary a bad (business) decision. I talked about Android, but most of what I said also applies to iPhones. While I do think smartphones will eventually end up in hands of practically all phone users, I do not believe that economies of scale or environment will work equally for all. I am not sure if designing mostly for affluent is wrong, but I do think it’s sad.

Web Hours (spletne urice) is a series of web related talks that is happening weekly here in Ljubljana and is free for everyone. Today’s talk , happening on sixth anniversary of the first , will be 181th. A lot of people shared a lot of knowledge and our community has grown from a handful coming to first few talks to few tens of regular attendees. We never made a really serious effort at counting, but I would be surprised if few talks haven’t drawn close to a hundred people. My congratulations and thanks to all who made it happen!

I started Web Hours on Andraž’s suggestion because I was not happy with  the quality of work done in Slovenia and I thought regular web talks could educate and help raise awareness. Looking back at the state of industry then and where we are now, it is obvious we came a long way and I’d like to think our talks played a part in it. I may be biased, but not that much because I stopped organizing them a long time ago so kudos really goes to those who followed me .

It is still easy to find shoddy work , but this will never change. You can find it in any field and there is no reason why web should be any different. There is always room for growth, but I am fairly satisfied with Slovenian web development community. These days there is no shortage of interesting events (meetups, hackdays, camps of various kinds) where you can meet kindred spirits, many of whom are doing interesting stuff. I wish there was more open web evangelism, but talks always were what we made them and it’s up to us open web advocates to go out there more often.

On the other hand Slovenian UX community depresses me. It seems to be full of people with big egos, very limited knowledge and low self-esteem resulting in an environment where constructive criticism is avoided and learning remains personal and, as community, slow. There are exceptions to this, but right now it seems it is enough to read a couple of books and follow a few related blogs to justify a UX related title on your business card and profess expertise. Critical assessment of problems and approaches is largely missing. There is a difference between cutting corners and skipping all steps — being agile is not a justification for being lazy. Events are rare and online discussions feel limited to regurgitating blog opinions as facts and discussing eternal, but mostly answered questions (e.g. how much of underlying technology do non-developers need to know?).

Then again I may be just an old grump. My feelings about UX community are not all that different to what I felt about web development community six years ago and that one turned out OK. Maybe I am just too quick to judge and things will turn out just fine soon enough. We’ll see. See you tonight in Kiberpipa .

I attended OpenData hackday previous weekend where we tried to create a website inspired by theyworkforyou.com . We didn’t quite achieve our goal, but a lot was done by everyone and we had fun. At least I did and I am certain we will release the first version soon (before the end of October, mark my words).

Not releasing our website still bothered me and I’ve been thinking about it since, contemplating what we did right and what I did wrong. I hope this rumination can be of use to others who may be thinking about organizing or attending such an event. If you already have and have some tips to share or simply disagree with something I said, then please leave a comment at the bottom.

Planning

It is important to finish something. Having something at least a bit useful or fun gives everyone involved a sense of achievement and provides a better motivation for further work. To avoid problems with too many ideas started and none finished, we suggested to work only on ideas that have at least 3 volunteers. We also created a wiki where everyone could add their idea and volunteer for projects they liked.

I think strongly suggesting at least 3 volunteers per project idea had an effect of ending up with just one idea. Not our intention, nor necessarily a problem, but it’s worth keeping in mind. We all tend to take the path of least resistance when not really committed to an idea and joining is easier than finding an idea AND people to help.

However if you do come up with an idea, then here are a few things you might keep in mind:

Self-sustaining projects win. Even with best intentions you will probably run out of time for your project eventually. So projects that can be finished or which can be run by a community with few development and administration resources are less likely to end in failure.

Strip it to bare essentials , but keep a list of things you’d like to add if you had more time or help. I knew that we couldn’t build theyworkforyou in a day, but my planned version was still too grandiose. I should stop only when removing anything would reduce it to useless. Another reason for this is that I also often overestimate my free time — important for projects that will continue after hackday.

Check if you have data you need . First check for completeness, since missing parts might significantly affect feasibility of your project (especially if they are needed for a stripped down version). If you plan to scrap data from a public source (instead of using API or something you already have), then scrape it well before the event. Site may not be available when you need it or, as it was our experience, it can be frustratingly slow. Perception of speed is relative, but downloads can always go slower than even the pessimist in you would make you believe. I learned on hackday that I was planning to use a non-existing data.

Check the quality of your data, don’t only glance at it. Spend some time getting to know it and think about how you will clean it up. I knew our data was in an atrocious state, but I was still widely optimistic. Luckily Tomaž is a seasoned data wrangler that can deal with crap input.

Have a detailed TODO list . Not only will it give you a better picture of scope, it also makes it easier to divide work to unexpected volunteers. Mark what is necessary and what would be nice to have. Also pay attention to skills needed for finishing each task. Gašper put a lot of effort into our to-do list and I haven’t. We could certainly achieve more if it was clearer what needs to be done and if I could delegate better.

Have a “roadmap” . Not every task can be done in parallel so identify and mark task dependencies. It may also be quicker if multiple developers extract different information from the same piece of data then for everyone to wait on one person to extract all.

Prepare hosting beforehand. If you plan to host a website, then set up and test at least essential parts before the event. Day passes too quickly even if you don’t waste time setting up the environment.

Ditto for development environment. How many people do you think will or can work on project(s)? Are they all familiar with tools you intend to use? Do you have adequate resources?

I expected time constraints to prevent us from auditing code for exploits, so we opted for bitbucket which gives you private repositories for free. But we had to juggle around its limitation of 5 developers per repository and choice of mercurial as DVCS. Having them private turned out to be unimportant.

So pick tools most are comfortable with and set up your own server (before the event of course) if publicly available options might not be good enough. You want everyone to start contributing as soon and as easily as possible.

Running event

Our hackday was as open as it gets. We used Eventbrite for registration, but didn’t enforce it so everyone who came was welcome no matter how long they stayed. It’s fantastic when people show up offering free help and it would be plain crazy to turn them away. There is always something they can do no matter what their skill set.

Here are a few tips I wish I followed:

Lead. Self-organization is great, but the likelihood of misunderstandings and duplication of effort quickly increases with the size of a group. If you have dependencies in your project roadmap, then it’s also important that showstopper tasks are done before those that rely on them. That’s why someone usually has to lead development and if a project doesn’t have that someone, you either have to find or be him.

Talk to everyone. Find out what they are doing or what they would like to do. Find out also how long they intend to stay, since that might limit the choice of suitable tasks. Talking is pretty much the only reliable way to find these things out.

Even better might be to have short group meetings throughout the day for everyone to catch up and I regret I didn’t think of this then. This however doesn’t absolve you from talking, especially if contributors are free to come and go whenever they please as they might have not been around yet the last time you were catching up.

Delegate. As much as possible to as many as possible. Don’t play a hero trying to do too much. You can always pick another task later or help someone with theirs if you finish too soon.

In fact it’s probably better to help less experienced members with their tasks than doing whatever you are doing. Having a healthy contributing community is what makes or breaks voluntary projects so nurturing one is even more important than finishing the first version. This goes even more so for projects that can’t ever be really finished.

Morning after

Hackday is over and everyone has gone for a beer. Hopefully everyone is happy with results, but ambitious projects almost by definition can’t be finished in a day and the next morning it was amazing to see people continuing hacking where they left off the day before.

Not every hacking community is as engaged as ours. However we all have more or less the same needs. It’s nice to hear our work was appreciated and even better that it mattered. We like to help if we are not alone and if it is clear how. Thus I found email sent by Gašper a few days later a pitch perfect post-hackday message. He first thanked everyone involved, then listed what each and all together achieved and ended by what he intends to do next.

So, this is it. A long, but not exhaustive run through my experience of our last hackday which also took way longer to write than I expected. It’s time to go back to hacking!