Life & much, much more

Space architecture – a history of space station designs

To quote the beginning of the full article:

This article explores different priorities of human comfort and how these priorities were satisfied in standalone artificial environments, such as space stations.

If you’re impatient and just want to read the full article, click to read A history of design and human factors in Space Stations.

… or if you want a bit more background, read on …

I began investigating in more detail the field of space architecture last year. Although I had a bit of experience from the ISSDC, I was much more interested in real current designs as opposed to hypothetical scenarios.

Space architecture, and its parent field of design is a broad one. It’s an engineering challenge, an economic challenge, a logistical challenge, a political challenge, you name it. As an architect, the priorities of space station/settlement designs lie with the people that inhabit it. Simply put, you don’t call an architect to build a rocket, but when a person is living inside that rocket, especially if they’re stuck there for a while, that’s when you call your architect.

This means that when an architect looks at designing a space station, although they need to be aware of the technical constraints of the environment (gravity, air, temperature, structure, radiation, transport, health), their true expertise lies in understanding how to make people comfortable and productive within that space. This means that space architects need to understand to an incredible amount of detail how we perceive and are affected by our environment. Much more so than Earth architects, who have the advantage of the natural world, which is usually much nicer than whatever is indoors, as well as existing social and urban infrastructure. Space architects don’t have this benefit, and so the entire “world” is limited to what they can fit inside a large room.

This point: space architects are responsible for the happiness of humans, is an absolutely vital one, and unfortunately often missed. Too many architects are instead raptured by the technological pornography of the environment, the intricate constraints, or even the ideological ability to “reimagine our future”. No. The reality is much more humble: space architecture is about rediscovering what humans hold dear in the world. You cannot claim to reinvent a better future if you do not yet understand what we already appreciate in the present.

And so if my point has made any impact, please go ahead and read A history of design and human factors in Space Stations, where I walk through the history of space station designs, their priorities, and what architects are looking at now.

Space architecture - how cosy

Cosy, isn’t it? Also, a TED Talk on How to go to space, without having to go to space shares many of my thoughts, and would be worth watching.

Life & much, much more

Hello SevenStrokes: Building websites … a little differently

A few months ago, Chris Paplinski, Nathan Charrois, Kaushal Inna, Andre Brokman, Kelsie Rose and I, Dion Moult, gathered to create a company. Today, we would like to present to the world: SevenStrokes.

Sevenstrokes web development

SevenStrokes is a web development company but with a few key differences.

  1. Firstly, we see websites as a service, not a product. We don’t just build a website, we treat it as part of your larger corporate strategy.
  2. We build systems that mirror your day-to-day domain issues. We use a combination of behavior-driven development and code architecture that employs the same daily language that you do. This ensures our system makes sense not just in the software world, but in real life, and thus always move a step towards achieving your corporate goals.
  3. We follow many aspects of the open-source business model, ensuring that we assign the most motivated staff that want your site to succeed just as much as you do, and that full inspection guarantees your system integrity.
  4. We push for the latest industry standards and keep on pushing, even after launch. Websites are usually short-lived, but we’re changing that with a system architecture that maximises long-term life.

So what are you waiting for? Do you need a website built? Do you need somebody to help spearhead your latest online initiative? Check out SevenStrokes: Building websites … a little differently

sevenstrokes unique web design

Life & much, much more

Architecture and what makes good design

Given that my third year in architecture is about to begin, I wanted to talk a bit about what I judge to be “Good Architecture”. I’ve talked a bit about selfish architecture before and I want to expand on this.

Good architecture cares about other people and disregards our own subjective wants. I was first introduced to this idea back in the 2011 Flux Student Architecture Congress in Adelaide during a presentation by a New Zealander named Andrew Maynard. He switched to a new slide – split into two pictures. The left showing a picture of a typical Zaha Hadid shelter in her signature style, and the right showed the ubiquitous German bus stop.

Zaha Hadid vs the German Bus Stop

Andrew points out each picture and asks which is the better design? The winner, of course, is the bus stop. Why? Because of the following news headline: “Fake bus stop keeps Alzheimer’s patients from wandering off” ([source]/source).

These fake bus stops were put outside Alzheimer clinics. Previously, when patients were distressed, they would try to escape the building. The staff would then have to alert the police to track them down and bring the back. Now, they would see the bus stop, and sit there – waiting for the bus that would never come to bring them home. The staff would leave them to calm down, and after a while approach them and say kindly, “It looks like the bus is running late. Would you like to come inside for a cup of tea until it comes?” To which they would agree, calm down over some tea and biscuits, and forget that they were trying to leave.

This understanding of human needs and care for all parties (staff, patients, and society) is the hallmark of good design. It is in contrast to designing a prison to keep the patients inside, and in even greater contrast to Zaha Hadid’s socially-devoid self-indulgent form manipulations.

Unfortunately, folks like Zaha Hadid are worshipped and highlighted in our education, yet I can’t even find a name to attribute the bus stop to. You just need to look at the names of architecture firms to see the egotism – just notice how many are named after the architects themselves or their initials.

Become a better architect. Don’t be selfish.


What’s up with & Hello

It’s been a while since I last posted about, aka the KDE-www war series. It talked about the current design, and how to improve it. The series started with target audiences and conversion goals, picked apart and restructured the sitemap, revealed an initial design proposal with clear-cut priorities, and finally analysed the effectiveness of design.

Since then, the KDE-www team has gotten serious about rebuilding from the ground up and has started up project neverland. However, I shall now be continuing the work on under a new name,

You can visit right now – feedback is much appreciated.

One of the most important aspects of the redesign is community involvement. is built publicly online irrespective of the KDE release schedule. This is so that the community is free to visit it any time and provide feedback and leave comments.

There are a few differences between how is tackling the redo and how neverland is tackling it:

  • The Oxygen team is unpredictable. Neverland’s answer to this is to design without employing the blue-coloured KDE, Oxygen, Air, or Plasma-themed elements as part of the basic design- that way, it will still be relevant no matter what KDE looks like. instead regards Oxygen’s unpredictability as a fault of Oxygen, and does use the three biggest things which make KDE’s brand recognisable as it currently stands: Blue KDE, Oxygen, and Plasma w/ Air.
  • is documenting its design process outside IRC. wants to be 100% transparent with the development process, making sure that the community knows what’s being done, why, and can voice their opinions. This means taking things outside the IRC channel, as well as into real life. This is because any change to a significant visual thing representing KDE may mean changing KDE’s brand. This is not something to be taken lightly. This also means that doesn’t follow the KDE release schedule.
  • has a much smaller scope. Only pages within will be considered rather that neverland’s objective of a one-size-fits-all solution unifying all sites, including wikis, forums, translated versions, etc. This means that a lot of content will be filtered out, but quality should outweigh the quantity.
  • is following the previously outlined target audiences and goals. Neverland is following a more rapidly developed, iterative design approach, whereas marketing objectives have been laid out from the start in, and it will follow that.
  • Neverland is the currently heir to Although will perform exactly the same functions as, most of the team are currently working on neverland. As such, is being branded as an experimental alternative to – and will stay that way until either community or statistics prove otherwise. will not become

Well, I hope you enjoyed it! More will come soon. Just another week until semester is over and then I’m ready for a sprint :) Updates are being dutifully tracked on its WIPUP project.


Architecture Portfolio Walkthrough, Year 1, Semester 1

A while back, I announced that holidays had started (well, now officially they have, just handed in my last assignment today) and that I was going back to all my projects and blogging more. The latter, obviously, was a complete failure, but hopefully this picture-filled post (all 20 of then, oh yes) will make up for the delay in the blog schedule (it was also a good opportunity to practice using the camera).

This is a walkthrough of my year 1, semester 1 architectural portfolio. There’s a lot of beginner-trash in it of course, but I hope I’ve condensed most of it from the around 150 pages worth of content. (Yes, you read that right – 150. That does seem excessive for a portfolio, but it actually isn’t that much, as they are double sided, and there were actually two portfolios, not one) So think of it as two 25 page portfolios really, plus extra content. Due to the immense quantity of work, I’ve cut out the majority and just focused on a few and will not have time to explain the details of each project.

The work inside was since March, so about 12 weeks worth of work, and the portfolio itself only had a week to create everything.

Note that for those who have been stalking me on WIPUP, some of this won’t be new stuff.

The portfolios were both presented in a stylishly hand-made briefcase. Yes, it is upside-down in the picture above. That briefcase was also the first proper physical object I’ve built before, so I”m quite pleased with how it turned out. An A3 sheet of paper fits very snugly inside.

Upon opening the briefcase, the audience is overwhelmed with tons of gewgaws and knick-knacks of every kind. For one of my courses, we were situated on the imaginary town of Cliffton (which has a landmark cliff, surprise surprise), upon which my building was a kayak manufacturing plant. The portfolio was designed as though a tourist had stumbled through the town and picked up trash along the way.

Looks exciting, eh? Well, let’s toss out the dodgily crafted kayak (needs lots of work) and the business cards with tiny sketches and drawings on them and look further.

The bulk of the portfolios were presented in two hand-bound hardcover books of cropped A3 and A4 sizes respectively. These held the parts which couldn’t be presented in more interesting formats. The A3 cover seems to have bent for some odd reason, perhaps its the glue.

The portfolio design itself was a very minimalist grid layout that some might remember first cropped up in my experimental web-folio user interface. Just smack in the center of the page. Pages were laid out in a “text” on the left, and “image-only” on the right per spread.

The left would always follow the same layout, and slowly build and construct an increasingly complex timeline of events as the person progressed further through the book. I found it a great way to put the work into perspective as well as to make the “text-only” section not so boring.

Some pages, however, with the more interesting technical drawings were complete spreads to-the-edge. The above we see a proposed abstract and conceptual transformation of the “CarriageWorks” site (a rather hip place here in Sydney, recently hosting TEDxSydney).

… as well as full-page renders, of course. People do like eyecandy.

… some of the more diagrammatic pages with thin strips through the page spread …

… and of course the napkin-sketches that show the birth of ideas.

More full-page renders – there is a lot of detail in these renders, which is why I chose the rather bulky pagesize of A3. (I find A3 landscape books rather cumbersome, but it was a necessary evil)

One of my projects involved the insertion of a set of rails and tracks into a back lane such that existing elements could be transformed and reattached into new layouts such that they performed different functions. (This wasn’t for the design course, but rather for the communications aspect, so let’s not look at why people would want to sit on bins and trip over tracks)

It was appropriate to create an IKEA-esque instruction manual (a separately provided A5 handbook) as to how to assemble the product, aptly named Konstruera Bagar. (name chosen by Erik Kylen) It means “Construct Arc”, I am told.

The insides are full of bad Swedish puns, unnecesary Swedish accents, and completely incorrect grammar, but let’s not get into that. It is, of course, also available in 80 different languages.

The design portfolio (the A4 book) favoured a more clean-cut “photos-only” showcase rather than the heavily diagrammatic approach of the communciations portfolio.

… here we see some of the detail in the tilework of the models done during design …

Along with the design book, a small fold-out visitors’ guide to Cliffton map was presented, offering both very scenic views and maps of the surrounding area and context, as well as a charming watercolour rendition of the building on the back – oh, and of course free coupons you can cut out.

My tutor was also invited to the monthly KayakersAnonymous pre-meeting congregation, showcasing the community areas of the building, and the various zonings that changed depending on the time of day.

Here we have the Kayak Maintenance Guide. It is probably important to mention that our imaginary town’s primary transportation system was kayaking through a system of canals. My building was essentially the town garage.

Apart from blabbering on about your warranty, the maintenance guide also details how to service your kayak, as well as exposes the internal processes of the buildings and various circulation paths you can take to minimize further damage to your kayak when coming to the building.

What briefcase would be complete without a newspaper clipping from the “Cliffton Times”, mischieviously dated Nov 11, 1918. It details the proposal of the building as well as the zoning decisions that were made within and outside the building site. It also pokes fun at some of my other group members – why not :)

Finally, two A1 panels of the final presentations from each subject.

Well, I hope that was interesting! I might post a PDF of the documents themselves, but that’s going to have to wait.


The kde-www war: part 4

A brief history lesson. The introduction identifies as a wall of text with a pretty frame and explains why there is a problem. Part 1 sets conversion goals on our two target markets. Part 2 restructures the sitemap to make sense. Part 3 dabbles a bit on concluding the design criteria for the homepage, and reveals the homepage.

In this part, we’re going to take a step back to the release of the homepage design from part 3, and talk a little bit about the science and justifications behind the design. Firstly, a quick note that the design was tweaked slightly after part 3, as the tweaked version can be viewed here.

All webdesigns are made up of three vital elements that work together to make a successful design. Keep in mind that these elements should be considered not just in webdesign but also by application developers.

Notice how the criteria outlined in part 3 addressed each of those 3 concerns directly. Now let’s took at how we’ve satisfied the criteria.

Let’s just briefly skim through brand – we have addressed this by emphasizing KDE’s visual identity:

  • The design has blue and white as its primary colours, which are KDE’s primary and secondary colours respectively.
  • Every single environmental visual element (ie – headers, footers, and non-content elements) on the page used visual styles from Plasma’s Air and Oxygen styles.
  • Every single functional visual elements (ie- the content element) on the page used KWin’s Air widget style.
  • All graphical symbology use Oxygen icons, especially to thematically link together concepts across the design.
  • The radical design choice of KDE’s first non-bordered layout corresponds to KDE’s philosophies of “Experience Freedom”, “Be Free” and “Breathe”.
  • The lightened fonts after tweaking now also corresponds to KDE’s aforementioned philosophies.
  • The iconic Kabel font is used for the KDE logo.

Now we can ask ourselves when we ask “What does KDE look like?“, as soon as we lay our eyes on this design, we can firmly answer “Yes. Of course! That is KDE!

Now let’s look at the content. Content should always come before function, as it sets the scene and helps our users understand what they should expect from the page. We start by giving the most important bite-sized factoids: what is new and awesome, for our existing users audience, and what is this KDE anyway? for our new users audience. We do this by giving a large banner to represent the latest news for the existing users, as well as a large, digestible (free from jargon) definition for the new users. What is more important is if we study why we placed the elements exactly where they are. Let’s study the eye-movements as a user scans the webpage – red being spending more time looking at it, and green being quick glances:

Firstly, let’s just jump back to reality. It is important to realise that people do not scan a page top-down, they glance top-down, then return to the top then proceed to zig-zag occasionally. This means that some people might jump from 2-5, instead of 2-3 (ie- visually oriented people). Also, people do not analyse in detail whilst glancing through – they search for vital factoids and discard everything else. These have good and bad implications:

The good – this pattern and step-by-step process to grasp interest is aligned with the goals/roadmap we outlined in part 1 of this series.

The bad – we are heavily relying on the effectiveness of elements 2 and 3 to provide the vital factoids.  These must grasp interest. Element 3 will target the text-orientated people, who will hopefully see:

Notice how we have successfully separated people from product, and are marketing KDE as a community. The user is immediately not looking at “Hey, download powerful software and a new desktop interface!” (akin to “hey, get free animated emoticons now!“), but instead looking at “Hey, I’m the most important person here, and something is happening which involves me. Something to do with powerful software and beautiful desktops, which are lovely keywords which everybody can say ‘yes I want it’ to. What am I missing out on?“. This will bring them to element 5 – to Discover KDE, and start their journey.

For the picture-oriented people, element 2 is our vital grasper. As the design stands now, it is obvious that the eye lingers longer over the left side of the image (put the more beautiful part of the image there, then?) but otherwise the image is completely unenticing and uninformative. It shows a rotated desktop screenshot and that’s it. This is bad. This should be changed. The blurb is useful though, as it not only says there is some sort of release with a really long fancy name (Software Compilation, anybody? 6 syllables?), but also zeroes into the single key features why it is so awesome. However there is clearly work to be done on defining a visual style for the header image.

Finally, let’s look at the function. What the user will want to do on the webpage.

This is a little tricky, as the homepage is a hub, not a content deliverer. It’s function is as a signpost and not an infographic. For this the design’s function is to direct users to the right page, and allow the user to understand the structure of the webpage, so that he knows exactly what to do next and how things are categorised.

We’ve already done a bit of this by piquing new users’ interests with the blurb and having their eye naturally fall onto the “Discover KDE” part. However let’s take this a step further by thematically linking certain keywords on the page through sequencing them in the same way, as well as using visual icons to mark their similarities. This can be seen below:

This helps the user understand the site’s structure, or three main “sections”, and emphasises their importance through repeating the sequence again and again. Thus the “About” and “Give Back” sections are already given less priority as expected given our goals outlined in part 1 as well as our restructuring labels in part 2, without entirely ignoring them.

This also performs a very important function of all design: the ability to give the user the impression that they have freedom to choose a path, that they are in control, but subliminally guiding them through a sequenced, optimum path. The user is presented with – yes – the entire sitemap. They can read through every single link and understand exactly what the page contains, but are still inclined to follow the three set paths for them. Also shown in the tweaked layout is that only the Community column is highlighted whereas other sections are greyed out – this will not be so on the homepage (all will be greyed out) but this helps users understand which section they belong in (other colour visual indicators will be in play later). This achieves the structural segregation that the original redesign was aiming for, without being too intrusive or clunky.

I’m going to stop here. Those were the main points I wanted to talk about to help raise awareness of the importance of design. I hope you enjoyed this series, and I’ve submitted it as a GSoC proposal, so if all goes well, we can start seeing things live soon!


The kde-www war: part 3

Just a quick history lesson. In the introductory post we highlighted several tell-tale symptoms that had a very big usability and design problem. In part 1 of the war, we discussed a back-to-basics question what are we trying to communicate, what are we trying to achieve, and outlined goals for our various target audiences. In part 2 of the war, we started to achieve the goals outlined in part 1 via restructuring the pages and site map in order to distinctly separate between the KDE: The Community and KDE: Software. In this part, we’re going to focus on the home page – the central entrance hub for new members, and how we can use design elements to achieve part 1’s goals, and still cover all of the masses of content that KDE has to showcase in a streamlined manner as in part 2, and even reenforce KDE’s identity in the process.

Now that we know what we want to achieve and the structure of, we can start thinking about the layout of the home page. The home page is – obviously – the most important page of the website. It acts as a central hub to link together everything that KDE has to showcase, it acts as the first stop for information for KDE newcomers, it acts as a publicity and news broadcast, it is the link between the various KDE sub-communities and communication channels, and most importantly, in today’s web-centric world, it defines KDE’s visual identity. After much debate, it had to satisfy the following criteria:

  • Embodies KDE’s visual style and branding – ie, the Oxygen, Air, Breathe, and Be Free. It should be a design that when you see it, you say “that looks like KDE”
  • It had to make people get KDE. To understand KDE not as a product and a software suite, but as a community. We want them to share with KDE’s passion. KDE has grown further than just a collection of apps and a desktop interface, and thus we can no longer be so shallow as to market it as such. We must follow our rebranding efforts to separate people from product, and emphasize open-source’s greatest strength – the community. We are a community, not a company. We create passion, not products.
  • It had to showcase our latest and greatest event/release/activities. However we need to showcase it in a way that people understand. Saying “Akademy 2011 is here!” alone doesn’t mean anything. Nor does “KDE 4.6 released – experience freedom”. Let’s change that to have meaning.
  • Clear segmentation between Software, Community and Development sections – to succeed where the current design fails. Let’s not make it a maze.
  • Absolute directions towards the goals we outlined – Goal 1: to become a user of KDE. Goal 2: Say hi and tell us what’s up. Goal 3: would you like to scratch your own itch?
  • Allow the user to understand how the site is structured and what exists without overwhelming them.

For this part of the war, I’m not going to write a wall of text. I’m just going to throw out the design right now, and let it speak for itself.

More to come. Let’s make a change.


Help defeat the wall of text.

Everybody knows that effective design is very important to any succesful interface – be it an application, a website, a product, or a physical structure. There are lots of reasons behind this, but the one I’m going to talk about today is how design combats the most dreaded wall of text, of which is a victim.

(Note: if you’re not interested in reading this post, just skip to the last paragraph where you can help give your 0.02 cents)

Somebody famous once said that it’s very easy to write. So easy, in fact, until the problem wasn’t with finding things to write about – it was finding things not to write about. The question was how to write concisely: boiling to the essence of what you’re trying to communicate to the audience, and how to present it.

But why is it so terrible? Despite what literature students tell you, people do not like to read. Ideally information should enter their brains without having to make any concious effort whatsoever. As interfaces are all about sharing maximum functionality with the user without sacrificing usability, knowing how to minimise (or present differently) the use of text is very important. Here are a few points to consider when critiquing – it is by no means complete and is not applicable in all scenarios.

You shouldn’t need explanatory paragraphs in your interface.

If the explanation is about your product, it’s ok to have it, but it shouldn’t be as long as a paragraph. If the explanation is about how to use your interface – that is the ultimate evil. The easiest way to remove these is to find isolate the most relevant element of the interface to which the explanation belongs to, then only make that explanation appear if the user is interested in that single option. Another way is to split up your interface into multiple interfaces to reduce the complexity of the things the user has to absorb in one go.

Don’t have more than 10 items in your main navigation.

Unless you expect a lot of repeat visitors who know exactly what they’re doing, of course. The point is that newcomers don’t like choice. They like the illusion of choice, but it is your job as the designer to secretly guide them through to the optimum “first impression” route. If you want to sell a product, you want them to be intrigued by X, then be introduced to Y, then be amazed by Z. And in that order. If you offer a service, you want to think what your target user’s daily functions are, and make sure those are in your main navigation. The rest, stuff it elsewhere.

Icons help. They really do.

Icons speak for themselves. A red X means more than a “No”. A greyed out X means more than a “Not available”. An “i” in a circle means more than “More information”. You can forego the word “Profile” altogether if you use an icon of a person. Plus, icons make your interface look prettier. If anybody isn’t sure what an icon does, they can just hover over it.

Be careful of how you present dates.

Dates are the easiest way to reduce readability of your interface. When given the date 04/05/06, Americans will read it 5th April 2006, Europeans will read it 4th May 2006, and Chinese/Japanese will read it 6th May 2004. The entire string “04/05/06” looks like code, and your brain has to do an awful lot of deciphering to understand it. It’s often best to give a full string “4th May 2006” if it’s in the archives where dates are important, a “Last Month” if the user is likely to only be interested in relative dates, or “4 May” (omitting the year if possible) if space is tight. The date is rarely the most important piece of information in a system, so hide it somewhere that only interested people would see.

Present your text semantically.

On computer systems it’s easy to think of text as lines with line breaks. Instead, get back to thinking of text blocked into paragraphs, with presenting one point per paragraph. If you have a list, use a list. Of course on the internet CSS makes this easy to do.

Create consistent visual format indicators.

Bolding text is good for emphasis, colour signify more information, italics hint at “quoted” text, font sizes represent importance, and alignment influences the workflow. It’s harder to do this on desktop applications, but still possible.

Over the next few weeks I will slowly document exactly how we can put this into practice through a live sample of KDE’s website. I will analyse each page and document it here. My objective is to not only beautify and improve KDE’s website (not only defeating the wall of text, but also improving it all around), but to also increase awareness about this in all of KDE’s applications.

Before I start, I need to collect some qualitative data from you, the community. Simply leave a comment to this post answering the following question:

Do you use (as in, not any subdomains such as the techbase, userbase, dot, etc)

If yes, was it a one-time “tour” use, or do you go to it regularly? If it’s a one-time, what do you expect to offer you? If you go to it regularly, what do you check most often?

Cheers, and until next time!

Life & much, much more

Design, photography, and servers.

It’s been a hectic few days. First off, I was pleasantly surprised to read on the KDE dot news that the KPresenter template contest winners were announced. I was very happy to hear that my submission had been chosen for 1st place! Here’s a picture for those too lazy to click.

Secondly, I’ve been learning a little bit more about photography, and so here’s a little preview of one of my photos. I decided to burn-in the Gentoo logo on the bottom right so that it serves as a nicely patriotic wallpaper. It’s a vague enough shape to be mistaken for part of the picture, but recognisable enough to be Gentoo (I don’t like in-your-face logos). You can download a high res version here. Here’s a snapshot for the lazy. Perhaps other Gentoo users might appreciate another wallpaper!

Finally, I’ve purchased myself a basic VPS plan from JohnCompanies – of whom is the parent company of a very commendable company called, of whom I’m still very happy with. Although not as cheap (as in, cheap + high quality reviews) as alternatives such as Linode (who offers double the resources at the same price), I went on a gamble that my great technical support experience will transfer over into a similar great experience.

Unfortunately, JohnCompanies does not offer Gentoo on their VPSes, only on their dedicated server packages. After some quick debate, I went for Debian. I shall proceed to migrate a few of my sites to this new server as well as a few of my existing hacked-together serverside toys. If you experience any downtime or shoddiness with any of my sites (blog + email included), it’s probably just due to the migration.


Progress on E2 Portfolio was my first ever (proper) website. I’ve recently been in the progress of converting it into a dynamically-updated online portfolio/playground. It pulls results from my WIPUP WIPSpace and displays them in a unique, portfolio-worthy layout. Last weekend I got the opportunity to turn one of my ideas into code – but there are still many things to work out, fix, and implement. Experienced developers would immediately notice two – the usability issue on the "more" button (not many realise you can click it more than once), and the 40×40 thumbnails, which are pretty much useless for actually displaying anything other than a slight splash of colour.

There is a demo hosted on WIPUP, so if you’re interested I would appreciate your comments.

Please note that all thumbnails are currently just placeholders for future thumbnails which will be pulled directly from WIPUP.

Sorry for the lack of blog posts, I have been working on quite a few stuff as well as some real life projects. There will be a minor WIPUP release on the 23rd to bring some polish to the system and to fix bugs.


Walkthrough of a CSS3 website design slice.

Slicing is a sign of a terrible golfer. Slicing is also the process of cutting up an image design into smaller images and writing markup code to turn it into a living, breathing website. I recently got a request from a friend to slice their portfolio website. Here is the original design he sent to me (and dumped on WIPUP as well).

It is a fixed width, fixed height website design. Technically speaking, it’s a rather simple design. Most website frontend coders would just launch right into slicing, but this time I wanted to have some fun. I wanted the freedom that any slicer and designer yearns towards – perfect separation between presentation and content, and complete disregard for browser compatibility.

Yes, if you haven’t already guessed, I built this site with CSS3. The only images I used in the end were the green background image, and the splash screen background image (oh, and the leaf icons for the navigation, but those don’t really count).

Most of the layout was straightforward using things like the new border-radius and box-shadow tags. However the lump in the navigation bar posed some complications. In the end I was able to recreate it using a three-layered solution (via the z-index tag). The first layer held the navigation strip with shadow effects. The second (above first) layer created the lump in the navigation’s shape and shadow. A third layer mimicked the second except with a slightly decreased width, slightly offset at the top and a shadow of the same colour as the background to create a "fading" effect for the shadow on the sides. With position: relative, and offsetting to place them, I managed to recreate the effect pretty darn well, if I might say so myself.

Finally, I used Google’s Font API to choose a more appropriate font, applied text-shadows (with a different colour in my a:hover tags to create a nice glow effect) and stuck it up online for my friend to see. Here’s the result (output via Gecko renderer):

This multi-tab bar is a common webdesign element, so this trick might help other CSS3-yearning developers. Here’s the code for those who are interested. The design works in Firefox, Opera, and Safari. Chrome does not render rounded shadows correctly but otherwise works fine. It fails with IE8 and below. Haven’t tested IE9.


Application design polish.

Free software is great. Everybody loves free stuff. However there’s one common flaw experienced by a lot of free software – they look ugly.

The reason behind this isn’t because we have too many programmers (yes, we know you never have enough programmers) and have too little artists – no, the problem is a lot more subtle. The real problem is that there is no clear hierachy within the artists. There is no control. There is no clear structure, focus, and branding. The question so many artists fail to ask ourselves as a contributor to free software is – What do we want to communicate?

To illustrate my point, I would like to use Ubuntu as an example. Regardless of your prejudices for the distribution and/or Canonical, they did do something right – they have a brand. They have a clear, recognisable pallette and style – from colourschemes to typefaces. Why don’t you see it for yourself: go and visit Notice the colours. Notice the icon styles. Notice the typography.

Another example of a project taking the steps in the right direction is KDE and their Oxygen iconset + plasma "Air" attempt. However there is still far to go.

However the issue does not lie with such large FOSS projects such as the above mentioned. Instead the real problem lies with smaller software and application created by smaller developer groups. The reason is because these small applications rarely have to worry about problems such as branding – instead they have to focus on creating an elegant application. Design elegance can only rely so far on the design of widgets in the UI toolkit used. The rest is really up to the developer. Allow me to give a quick visual example of Blogilo, a blog client which I’m using to type out this post. Take a look:

The untrained eye would not see any problem with the screenshot – however the application design above screams complexity. There is no elegance. There is no simplicity – no "flow" (a clear step by step separation of functions). A blog client is not a complex application like an IDE. It exists for you to add, edit, and delete blog posts. Nothing more. When stripped down to its basics, a blog client is naught more but a rich text editor with a few extra options. Instead we have frames within frames, accordion panels, tabs, and buttons strewn about. Overkill, in my humble opinion.

Design polish is a very hard topic to separate what is ugly and what isn’t. It’s blends over into many neighbouring topics such as usability, a macro-view of marketing (in this case, Blogilo is part of KDE), and functionality. If you are interested, however, I would like to direct you to this very interesting blog by Troy Sobotka, one of the folks behind Ubuntu, who discusses this in much more clarity and detail than I am capable of.


Plans for to turn into a personal cloud?

Alert! Alert! Buzzword! Yes, before we start, let’s clear up with what I mean when I say "personal cloud". A personal cloud is a web-accessable system which centralises the function of common web 2.0 services, which may or may not be social. For those that aren’t familiar with this jargon, web 2.0 services are those such as web email clients like GMail, photo sharing and management sites like Flickr, online radios like Last.FM, and even blogs just like this one. So your personal cloud is a system on your very own website, with a web interface for your very own emails, PIM (calendar, notes, todos), images, music, etc. Note that the social attribute is optional. Clouds do not have to necessarily have automatic synchronisation, nor does it have to have the ability to easily share your data with the public.

A little history first. used to be the center of attention – thriving with the latest adolescent community fads such as animation, art and music "portals". It later saw the rise of the Blender Model Repository, a personal portfolio, several forums (trendy, weren’t they?), and finally ended with the death of the original animation portal. thinkMoult then emerged somewhere on the Blogspot blogosphere and went on to become a moderately-hacked install of WordPress on the E2 server. E2-Productions had become, and still is now, a dead site.

I’ve been toying with the idea of turning E2-Productions into a personal cloud for quite some time. It did actually occur at one point. Even though a PHP developer myself, it would take too long to create my very own cloud to implement existing free scripts. In the end I had created a network of individual PHP scripts giving me a web based RSS reader, filebin, imagebin, and a proxy. With the helpful addition of several rsync scripts and sshfs, it was usable and offered all the functionality. However of course it was very hacked together and didn’t offer the sort of integration I wanted.

Today I decided to look into other cloud services. One currently in development is ownCloud by Frank Karlitschek, the guy resonsible behind the openDesktop websites. Unfortunately the results were disappointing. Taking into account that it’s still under construction (and therefore incomplete and buggy), like the openDesktop websites themselves, ownCloud is unfortunately yet another developer service that underestimates usability. Whilst it had some nifty features in the works, it’s priorities were skewed away from the rightful mentality that design maketh a website, not the function. Further probing into the code revealed some serious problems with the structure of the coding that didn’t look very well thought out. Needless to say ownCloud is not for me.

The other famous personal cloud is the open-source EyeOS. This one goes all the way, completely replicating the desktop interface in the browser. Again, most of the design of EyeOS 1.x, their stable version, approaches the design of the system as a desktop interface. The canvas of a webpage is not suited for a desktop interface. They both have strengths and weaknesses and unfortunately most of these uncanny designs don’t play to the webbrowser’s strengths. Despite the overblown interface (which excusably is amended quite a bit in their 2.0 unstable version) it’s quite featureful and its extensibility in terms of developing it yourself is quite attractive. However the lag which accompanies such client-side interactive bloat (and server-side too!) doesn’t exactly make it the most practical of choices. It’s definitely worth keeping an eye on, though (excuse the pun).

Further searching yielded an exemplary system called Tonido. Unfortunately due to its proprietary nature it’s not for me either. However it does provide a fine example of the potential of a well executed cloud service. This motivated me to reconsider creating a cloud. I began with considering the basic user objectives for the web interface:

  • Ability to dump a file online with a unique private URL, and easily share it via public URL (or a single obfuscated URL).
  • Private browsing of my files with support for subdirectories.
  • Browsing of images will be represented in userfriendly thumbnail form.
  • Browsing of PIM data (vcard, ical) will be parsed and displayed in an appropriate format.
  • Web-based uploader and/or form of synchronisation technique.

You see the "cloud" I had described (in terms of its most basic user-side functionality) as such is pretty much just a smart web-based filebrowser with mini-webapp additions for (mainly) PIM-data. Our latest newcomer to the fad, Ubuntu One, actually provides these needs very well – leaving the browser to do what it does best, and the rest to the desktop. However it falls short in a vital area – proprietariness. This isn’t a question of evangelism, it’s more of one of the simple requirements of a personal cloud. If we analyse the 5 basic user-side needs to its roots, we get a shorter list of what actually makes a personal cloud, personal:

  • Fine control of private, limited, and public files.
  • Convenience – data should be searchable by tags, and there should be no limit on the filestructure or methods of access.
  • Timelessness – data should not be locked into any vendor.

The first issue is tackled quite well in existing cloud providers, with probably the best implementation (in my opinion) being Ubuntu One. Convenience is another easily satisfied need, with wonderful tools like rsync, sshfs, and version control software (though again, most providers lock you into their own system, and convenience ends once you leave it). However the key feature that in my eyes hasn’t yet been solved by any provider is timelessness. Any proprietary client or syncing software is instantly disqualified due to dependency on the vendor. Now, even if the software was completely open and extensible, many so called personal clouds are simply connecting to existing external services. Whilst consistent with the definition of the personal cloud, the service centralises in what is hoped to be seen as the path of least resistance – that is, only for people actually already using those services. What services am I talking about? Oh, things like Flickr, Google, Facebook and Twitter. Social is a hot topic, but not for everybody. Services don’t even have to be online – dependency on, for example Tomboy Notes or Evolution in Ubuntu One qualifies as a dependency and thus means the service is not timeless.

So how is this overcome? Not easily, for sure. I want to propose that the ideal personal cloud be one that focuses simply on file management and synchronisation. It should stop there – the actual display of files and searching of files should be handled by plugins. Plugins can decide how to properly format an image gallery. Plugins can decide how to display PIM-data. These plugins should be accomodating for the most timeless format ever, plaintext, as well as industry standard formats. The user then only applies the plugins that fits their exact workflow, if necessary writing their own for interpreting their own files. This satisfies the 3 criteria of a personal cloud.

I’m still coming up with a few plans and extra ideas on how it’ll be – but meanwhile I’ve got exams to get over. If anybody knows something similar that exists, let me know, otherwise this’ll be a fun project after WIPUP reaches stable.


A little typographic poster

A little while ago I was requested to make a page for my school’s yearbook about our Graduation Ball. Being myself, I don’t really condone scrapbook-like designs full of wacky, fun, and generic designs. So I produced a typographic poster. I haven’t actually done this style before, and I must say it was an interesting poster to create. It’s nothing very “wow”, but I decided to share it there. Perhaps some people would appreciate it, after all, the purpose of this blog is also to “every so often whack up something that I create”. Here goes! Click on it to view the full size.


Comments welcome but unnecessary really ;)