Creative

USyd Architecture Exhibition website released

Today I’d like to officially release the Usyd Architecture Exhibition website.

USyd Graduation Exhibition Website Homepage

USyd Graduation Exhibition Website Catalogue

Taken from the site itself:

The University of Sydney Architecture Faculty puts together an annual exhibition for its graduating Bachelors and Masters students. This gives students an opportunity to showcase their best projects. An event is held to exhibit these works, and along with this a hardcopy curated catalogue and a digital catalogue is released.

So as expected, the site hosts this year’s digital catalogue, and will continue to host future year’s submissions. There are currently about 100 submissions listed across five diverse project briefs. Feel free to look around, but I’d like to issue a word of warning to my readers that you might find the project descriptions more affiliated towards the romantic and social science-esque narrative.

If you’re wondering why a lot of the work is more art than design, I’d like to highlight that we aren’t incapable of making functional, logical and real-world problem solving designs. However it does seem that a lot of students aren’t taught how to write, and end up romanticizing the design into an artwork. That said, some designs do aim to be utopian and speculative, but I guess if you’re going to be spending the rest of your life looking at glazing and bolts, you’re excused for a little fun during university.

I’d also like to get the chance to highlight my own submission on the website.

Flinders Street Hotel Proposal Render

My project this semester involved proposing a Flinders St Hotel. It’s a rather large scale project, and would take too long to explain fully, even for the generous space that the online catalogue allows. I recommend viewing my project page and reading the full description there. It gives an overview of the project.

Finally, I’d like to quickly highlight the under-the-hood of the website. The website runs on vtemplate, is responsive, and has it’s technology colophon visible at its humans.txt. In particular, it was designed to be quite generic and highlight the work itself, and function on a phone or iPad as you scanned QR codes during the event itself. The entire website is open-source (view repository), and I’ve just tagged 1.0.0 today :)

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

Technical

Content Management Systems harm websites

Yes, you read that right! Customers looking to build a web application are often wooed by the many ‘benefits’ of using a Content Management System. But before we begin: What is a content management system (abbreviated CMS)?

When a web site is built, complicated code is written to allow it to function. Some of this code builds what we see on the surface on each page. For example: the design of the site, the layout, and its content.

Content management systems harm websites

(Oh dear, we’ll explain that screenshot later!)

Web developers have built systems which now allows clients to edit the content themselves and have instantly updated content without having to go through experienced web developers. These systems are called Content Management Systems and supposedly pose these benefits:

  • Site content changes are seen instantly as the client thinks it up
  • Clients feel more ‘in control’ of the site
  • No need to pay web developers to make small and frequent edits

Sounds excellent, right? Cheaper, faster, and you’re in control. Well, unfortunately, it’s not the entire story.

What most clients don’t realise is that editing a website is not like editing a word document. CMSes create a rather similar interface which is easy to use, but causes serious side effects:

  1. The CMS editors don’t know how to cleanly separate content and style. This is the difference between what is being displayed, and how it should look like. This cruft builds up over time, making your page load slower and making it increasingly hard to make changes in the future.
  2. The CMS editors only allow you to change what things look like on the surface. Although you might not notice the difference, search engines are less likely to be able to understand your pages, and this will negatively affect your search engine rankings.
  3. They don’t discipline against bad media practice. These editors will let you upload any type of media without any considerations of how to optimise them for the web. Unoptimised images and videos mean slower website loading, more server loads (and thus server costs), and often ugly looking content.
  4. They add a lot of unnecessary code. This is another invisible side effect which leads to slower page loads and poorer search rankings.
  5. The editors don’t refer to the underlying engine when linking pages. This means that should you want to rename pages for SEO, or move site, your links are almost guaranteed to break.
  6. There is no version control. It becomes much harder to track series of changes to a single page and undo edits when problems occur.
  7. It gives you the illusion that you are an interface designer. Experienced interface designers pay attention to details such as padding, ratios, consistency, and usability that clients simply cannot match. A well designed site will slowly degrade in usability and aesthetics until it has to be redone from scratch.
  8. It lets anybody change anything. It doesn’t stop you if you’re changing a vital system page, butchering crafted copy that has undergone hours of SEO, or even edit the text of something you don’t have authority to. It becomes a human single point of failure.
  9. It exposes you to system internals. If you’re a client, all you really want to do is edit some text on your page. Modifying forms and dealing with modules is out of your league, and likely out of your contract scope. You’ll have to learn how to use a complex system just to change what is often just a simple site.
  10. You’re stuck with it. CMSes are walled gardens. They lock you into the system you’ve chosen and when you want something customised in the future, don’t be surprised when you get billed extra.

With the site almost fully in the client’s hands, clients can unknowingly break the system internals, or worse, install 3rd-party low-grade modules which can compromise the site’s security. With the power to edit now fully in the hands of clients, these system changes do not pass through the developers eyes. Over time, these accumulate and you end up with a broken site.

It isn’t all cheaper – to attempt to prevent some of these effects, developers have to spend extra time to develop custom modules for you to manage sections of the site. These costs, of course, have to be passed to you.

CMSes are also rapidly changing and constantly targeted by hackers. Not only does this mean you’re open to security breaches, the server will likely be under extra load by hackers and bots attempting to crack your site. You’re then pushed into a maintenance race to constantly update modules and your system that quickly gets forgotten: until you’re left with an outdated, unable-to-upgrade system that’s a sitting duck for hackers, even if you’ve never needed to make a single change to your content.

Did you receive training for how to use a CMS to edit your site? Bad news. You’re the only one who knows how, and probably not for long. CMSes change very rapidly – so your training will become outdated. There also isn’t much of a standard when it comes to CMSes, so you’re restricted to development firms who specialise in your CMS should you ever need professional help in the future.

Funnily enough, using a CMS is no picnic for developers, either. All CMSes cause developers to build things not the way they should be built, but the way the CMS forces them to build it. This may save time in the short-term, but often leads to costly maintenance nightmares in the long-term.

Together, using a CMS turns the craftsmanship of your site from the costly investment you poured into experienced developers into a cheap, ineffective website. You’re practically throwing away the money you spent going through detailed design revisions, search engine optimisation, training, website optimisation, responsive design, and even choosing the firm you hired to begin with. And given the accumulative nature of these adverse effects, you can be guaranteed that any changes you need done in the future will become much, much more costly.

These aren’t one-off improbable horror stories. These are things I have witnessed again and again with CMS-run sites. It is practically guaranteed to happen: the only question is when. The industry knows this, too – it’s just that CMSes are good at the short term and the prospect of self-editing content is alluring as a selling point. But it’s time to spend your money properly: get an expert craftsman to manufacture it right the first time, and keep the quality you paid for.

… coming up next: CMSes done right.

Uncategorized

The kde-www war: part 3

Just a quick history lesson. In the introductory post we highlighted several tell-tale symptoms that KDE.org 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 KDE.org, 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.

Technical

The kde-www war: part 2

Before I begin this (delayed) post, I would like to reemphasize that a sub-agenda for these blog posts is to raise community-awareness about design issues in KDE. The website is certainly not the only area where there are design flaws, and I was very happy to read over my Christmas holiday a couple a blog posts here and here by Aurélien Gâteau about design issues within applications. I hope we can see even more of these :)

In the initial post, we talked about the elephant in the room: the wall of text that is KDE.org. No solutions were presented, but symptoms were outlined. Then, in part 1, we discovered that the wall of text was partially a side effect of a deeper problem within KDE – the structure, or lack of it. We discussed KDE’s marketing objectives, and the corresponding misalignments within KDE’s website. We finished off with outlining the ideal situation in the future. Today, we are going to talk about achieving it.

KDE has a lot to offer. Our goal is to filter down what it offers based on their relevancy to target user groups. So before we start, let’s look at the current state of KDE’s immediate “sitemap” – this is what the visitor is presented when they first look at the site. I’ve divided them into columns that they belong in, and briefly described in bullet-points what each page does.

Yes, that was long.

Too long. In fact, let me break down the issues here:

Too much choice.

This is the biggest problem here. KDE has a lot to talk about, but newcomers don’t want to be slammed with all of that in one go. For websites belonging to smaller services, each navigational item can highlight a different issue without overwhelming the visitor, because each wrap nicely around a single point of focus. KDE has multiple points of focus. Thus, it should only provide navigation items which hit each topic, not sub-topic. Here are two other websites which deal with the same problem very effectively: Mozilla.org and Opera.com. As you can see, Mozilla ignores submenus altogether, and Opera has a very clear breakdown of the topics they deal with. All in all, nobody should ever be presented with 44 navigational choices.

Imbalance in choices.

Not only is too many items in “About KDE” confusing to the user, some areas in the Community section really seem like pagefiller on what doesn’t need to be included, and others are just a massive list of items. In contrast, the Workspaces section only has 3 links – which combined together really fail to deliver what they could potentially deliver. The user is left with a “is that it? Pages upon pages of history and verbose description about KDE’s past, and only a couple screenshots about what it’s like now?“.

Double entries in the navigation.

A big problem here is that the navigation headers themselves are links to a page instead of a plain divider as it is meant to be. For example, the “About KDE” is a link, and “Community”, “Workspaces”, “Applications” etc are also links. Often this results in the page being simply a summary of all of its sub-pages, which means information repeats itself, two pages have to be maintained in the future instead of one, and users get confused of where the “official” source of information on a topic is. The summary often seems half-motivated, just to fill up a page, with the only exception being the Dev. Platform page.

Ambiguity in categorisation.

The most immediate ambiguity that shouts out at me is the “Support” category. I immediately thought “How to Support KDE”, as is the norm on most other sites out there, but it turns out that it is actually “End-user Docs/Help”. Apparently I was not the first to be misguided, as seen by the later-added “Join the Game” link, which is therefore miscategorised. Similarly, a lot of the “Community” which I identified in my part 1 is nonexistent in the Community section, but is instead filled with links about “KDE: The Foundation”. The Workspaces and Applications category is also separated, even though it need not be – as they are often bundled together when presented to the user. The result of this is a half-assed workspaces section of the site which really undersells what we have to offer.

So, what now?

We have to completely reorganise the website, obviously. The new navigation has to:

  • Provide a smaller number of choices
  • Properly categorise navigational items
  • Remove stub pages that are unnecessary
  • Remove “summary” pages that are unnecessary
  • Hide pages that “only those looking for it should find it” (eg: About Free Qt Foundation)
  • Expose more of KDE’s community, (forums/planets/irc/mail lists/social sites/ocs/etc)
  • Guide users through our outlined optimum navigational route which is aligned with our marketing efforts (as identified in part 1)

Now that we have a clear list of goals, I spent a few days brainstorming and designing a new structure along with the kde-www folks. Here’s the finished product:

Less choice, less confusion.

This new structure narrows down the number of items to 29 areas. However, we’ve decided to not immediately present all 29 to the user, instead settling for showing only 4 items, Community, Software, Development and Support, with the About items hidden in the footer (only those searching for those pages should find it, we shouldn’t showcase it). We’ve merged the Workspaces and Applications sections into Software, which essentially is a visual tour through KDE, instead of splitting it up into single, solitary pages. The community section actually does have community links this time, and we’ve narrowed down the Development items to the bare essentials (open for debate, as the -www folk aren’t desktop-devs), as in general the devs know where information is kept. Ideally, the Development section’s objective is to make it easy for new coders to join.

It is a little hard to describe, but many pages have been merged and some even completely removed, and I won’t go into details describing why every choice was made.

Points of focus

I’ve highlighted with a blue square several points of focus, this are in general more important navigational items, as they represent key sub-topics in each section. Later on in the design phase we shall discuss how these can be emaphsised visually.

Aligned with marketing’s optimum navigational route

I’ve made two arrows in the diagram above, one blue and the other red. The blue represents the optimum path for our new users. It starts them off with “We are KDE”, to answer their question “What is KDE?”, then guides them through the Software section, a visual mosiac of pretty colours, screenshots and beautifully presented features to persuade them “Why is KDE awesome and why should I use it?”, finally, we land them at the “Get KDE Software” page, once they’ve said “OK, you’ve had me convinced. Let’s get started”.

The red arrow is slightly more complex, for people who already use KDE. Their landing page is the “Get Involved” page, of which the objective is to answer the question “Where do I fit in?” When answered, we will direct them to one of our many community outlets within the community section and help them start their journey with KDE. Alternatively, should they be interested in joining the technical aspects of KDE, they can learn about the Dev Platform, and get redirected to the Techbase, which should turn them into super geeks in no time.

That’s it for part 2.

Thanks for reading and I hope you’re enjoying this series. There’s still a long way to go, and you can actually keep up to date on it via the WIPUP project here.

Technical

The kde-www war: part 1

In my initial post, I talked about the wall of text. I described some of the symptoms of the wall of text, and proclaimed that kde.org is terrible. I listed some of the basics of cleaning up text, and gathered some information about the “why” of kde.org.

Unfortunately, KDE.org is representative of a very large and vibrant community, and although formatting and eyecandy insertions will come in good time, we have to first understand the site’s structure to make informed decisions before tidying up small details. KDE.org’s wall of text problem is not simply due to a few bad aesthetic choices, but instead a side-effect of a more fundamental problem in KDE-www’s structure.

When I defined the wall of text issue, I described the problem being boiling to the essence of what you’re trying to communicate to the audience, and how to present it. Thus let’s look at what we are trying to communicate to the KDE audience – of which there are essentially two parties:

The uninitiated potential KDE user

The new user is interested in the single question of “What is KDE?“. They will want to understand that KDE is a community, and that its product is KDE SC – of which is a multidimensional beast full of wonders both for end-users and developers. When this has been answered, we want to tell them “Why is KDE right for me?“, and finally when convinced, “How do I start?“.

New users have a very specific workflow, and so we should recognise this, tailor it to them, and remove any potential “sidetracking” factoids.

The existing KDE user

The existing KDE user knows what KDE is and is currently using it, but most importantly, the existing user IS KDE. The rebranding effort was not about changing KDE to KDE SC, but instead about separating product from people. Technically, open-source is simply a business model, but in reality, open-source is a philosophy constructed by people. KDE’s challenge is how to turn one of open-source’s most intangible qualities into an axiom for all users.

So let’s talk a bit about KDE instead of KDE: SC. It has a “magazine” of sorts, the Dot, which gives “official” news on the ongoing events in KDE. It has an active blogosphere by PlanetKDE, which is populated basically by the people behind KDE: SC, which report upcoming features, discussions about KDE-related topics, ongoing physical events, and ongoing virtual events. It has a micro-blogosphere, by buzz.kde, which highlights recent Flickr and Picasa activity, YouTube videos, Tweets, and Dents. KDE’s community also has the Forums, which acts both as discussions, support and brainstorm. There is a multitude of Wikis: Userbase, the by and for users, Techbase, the by and for developers, and Community, used to organise community activities. There is KDE e.V, which does awesome stuff which isn’t publicised enough, and a variety of groups in social networks such as Facebook and Linux.com. Freenode’s network has a collection of IRC channels where KDE enthusiasts hang out. There is a variety of regional communities which all hold their own KDE specific stuff, and an entire of network of community-contributed KDE resources through the OpenDesktop API, and various other KDE connections through the SocialDesktop.

For your convenience, I’ve bolded what is KDE in the above paragraph. KDE-www, being representative of KDE, must stress that this is what KDE is – firstly by presenting in a digestable form the amazing influx of activity from all of those sources, and secondly by making it easy for any KDE user, old or new, to find out where they belong, and how they can add to the community. If you look at KDE-www from this perspective, it’s not hard to come to the conclusion that KDE.org is terrible.

But where do we start?

Given such a complex problem, let’s start by mapping out the ideal routes for each user. Here’s the proposal:

When looking at the chart above, notice how we clearly separate KDE from KDE:SC. I would like to highlight that the two final goals for existing users are not mutually exclusive. You can both contribute to KDE:SC but at the same time contribute to KDE – as long as you communicate your activity.

Now that we have identified the ideal paths for our target audiences, we can start making informed decisions about restructuring KDE.org. But before I get to that in part 2, feel free to add your opinion.

P.S. There is some wrong terminology used when it comes to KDE:SC, it should be referred to as KDE Software, as SC is more of a technical term used to describe a specific subset of packages in KDE Software.

Technical

Help KDE.org 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 KDE.org 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 KDE.org? (as in www.kde.org, 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 kde.org to offer you? If you go to it regularly, what do you check most often?

Cheers, and until next time!

Technical

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.

Uncategorized

More do, less talk.

I’ve been a busy little bee these few days – you didn’t think WIPUP’s beta release would slow me down eh? Unfortunately for you folks, I like to strike a balance between doing and talking – sure, more talking and doing doesn’t see any results soon, but more do and less talk is just plain selfish. As such, here’s what’s new in Moult county.

Firstly – the the WIPUP beta aftermath. Could’ve hoped for more users, but I’m happy with how people are picking up on it. So far all feedback has been positive, and we’ve picked up a good few members along the way, some of which have become users. Now that I’ve signed WIPUP up on Google Analytics, we’ve got shorter, sweeter reults:

Because I like looking at the results in percentage increases, I’ll let you make your own conclusions this time.

Meanwhile, a few noticed that this release’s splash was not made by me – rather it was contributed by Nathan from Cetan.ca. This means that if anybody wants to contribute splash artwork, I’d be more than willing to use it – provided that it’s abstract, and that it passes as aesthetically pleasing – and of course credits will be duly given.

The ThoughtScore Project has resumed production – and surprisngly to some – not in any graphical area, but rather in the script. I’ve submitted what I’ve started on it as a WIP available here, and once I implement the “paste revisions” idea for WIPUP suggested here, I’ll allow you to actually write parts of it (well, if you really want to – but no promises on accepting them).

I’ve also been, despite sans internet for 2 days in a wonderful place called Bandung (reaaally beautiful if you go to the right places) I’ve also been busy giving back to the community in KDE. We now have a lovely release counter image (demo’ed below), my submission to their KPresenter template contest, and a little progress on the upcoming release announcement for 4.5. Not to mention I’ve also been in the middle of setting up KDE’s site for development on my localhost to tackle “polish” issues, of which you may see some of my critique here.

KDE Countdown

Of course I’ve still been doing part/fulltime work doing webdevelopment (on my 3rd project now wheyhey), and so if you need any webdevelopering done you know who to poke. Also, being in Indonesia also means I’ve been rockin’ with my relatives.

Come on, a post like this with loads of links definitely means I’ve been busy. Excuse the insightful-informative post tradeoff.

Uncategorized

WIPUP 19.03.10a released!

WIPUP is a flexible and easy way for people to share, critique, and track works-in-progresses.

Every month, the WIPUP website gets synchronised with the Git repository hosting the code. It wasn’t long ago at all since the February sync was performed (21.02.10) and since I’ve been having mock exams that generally means I have a lot of free time (well, a couple all-days after the mocks) which I’ve been a busy little bee whacking down features. So while I was initially fearing a "maintenance sync" I’m happy to announce a feature-packed release.

Release notes are in their full glory in the WIPUP Release, and comments should be left there, not here.

This is a massive update, and I highly recommend people to start checking out the rest of the site and try it out themselves.

Well, time for a break from updates then!

Uncategorized

Site review: BestWindowsMobileApps

This is a sponsored review by the owner of the website but all opinions are that of my own.

Windows Mobile 6.5.3 and below is widely regarded by many tech fads as a to-be-deprecated technology in favour of other smartphone OSes and possibly the upcoming Windows Mobile 7 OS, revealed just over a week ago. However much of the hidden credit behind the WM 6.x series lies in its ability to tweak and adjust the OS to such an amazing extent not really associated with Microsoft – all of these are found in 3rd party applications scattered around the internet that it takes such a long time to monitor the upcoming applications and find reliable ones. This gives the false impression that the system is underpowered. It wasn’t until almost a year ago that Microsoft released the Windows Marketplace, the equivalent of Apple’s App Store in order to solve this problem, but it’s a developer-initiative process to distribute using this system, and so many of the gems still remain hidden.

Those who have gone app-hunting would be familiar with sites such as freewarepocketpc, wm6software, pocketgear and the ever-so-reliable XDA-Developers forums. However we have a new kid on the block, BestWindowsMobileApps.com.

The site at first glance runs on WordPress with an aesthetic design that leaves little to be desired. This WordPress setup has all of the necessary plugins and additions which make the site appropriate to its purpose, including a featured application section, random apps, latest apps, social network sharing, related links (quite inaccurately labeled as a blog roll in our opinion), and the compulsory commenting system. It communicates its purpose extremely clearly and despite a seemingly random blank space on each sub-page near the header (probably for advertisements in the future), it looks extremely credible and up to date, which is a vital impression for such a site.

The site gives an unbiased review of applications submitted by developers and rates them on what I believe to be rather well-chosen sub categories: user interface, features, ease of use, and re-use value (if the app is a one-time use-and-forget or not), and for games graphics and sound ratings are also provided. Each of these are given a half-star rating out of 5 of which each rating is given a clear definition in their about page – 1 star for a application that wasn’t even worth the review and 5 stars for the perfect application that deserves recommendation to all WM users.

The site is two-tiered, splitting applications into two main categories, "Applications" and "Games", then further narrowing down the choice to your regular list of sub-categories such as communication, entertainment, lifestyle, media, etc. Although most of these portal sites have these categories this site is different in that it is completely centered around them instead of offering a more random browsing experience like others. Unfortunately there seems to be some navigation duplication in the main menu, such as Apps takes you to the same place as Categories -> App Store does, or we seem to have an unneeded single subcategory under Tools being Utilities, or that the supposedly macro-category of "games" is seen again inside Categories -> App Store, etc. Similarly we were shown this link to what seems like a "Games category" description page, but I haven’t been able to find a way to navigate to that page on the site. Perhaps because that page seems unfinished (some categories are not annotated) but this suggests a few fundamental navigation problems. This may serve to confuse newcomers but is a relatively easy problem to fix and on the whole provides a very instinctive navigational sitemap.

The list of applications is just as aesthetically pleasing as the rest of the site. It provides a quick snapshot of the name of the application, a dedicated icon (instead of other sites which rather badly autogenerate thumbnails) and a blurb. Although a little too much emphasis is placed on the date and reviewer than we’d like, we suppose it matches the feel of the site. Given that a one-liner summary of the app’s function is appended to its title it makes it really easy to find what you’re looking for.

An application’s review page does suffer from some visual glitches here and there that detract from the previous professional impression of the site. Some layout ideas could be rethought, such as placing the tags, post author and date and a rather large box with minimal information at the top instead of launching right into the review. However the review itself is presented in well-formatted narrative blog format not unlike this post and has plenty of app screenshots showing the app in action. It walks through the beginning impression, tours the features, and provides a consice summary to wrap up. The writing style is easy to understand and well-structured. Consistent throughout all reviews are a bullet pointed pros, cons and a possible improvements section at the end, your version number and price, the beforementioned star ranking system and an overall rating. A complementary link to the developer’s site is provided as well as a link to their sister site to download the product. The rest is taken up by social networking and comments which unlike most other review sites contribute quite intelligibly to the review.

Developers can submit their apps for review on quite ethical terms including unbiased reviews and understandable property rights. It’s a simple enough process and very appropriate.

Overall the site is quite polished with a few visual presentation quirks to work out. Some reviews are a little short (especially those with low rankings) but seem to communicate the message effectively enough. The duplicated navigation may be confusing, as well as some category structures needing to be rethought (for example, what is the "XDA dev" category?). The site is still quite immature in terms of content quantity (we’re predicting about 100 reviews, and we did notice some overlap in categories, which isn’t necessarily a bad thing) but from what exists, it’s some good quality reading for those on the hunt for the perfect application set. I must say I didn’t set my sights high given the existing cobbled and maze-worthy app portal sites but this one has potential.

Uncategorized

KDE.org relaunch with a brand new design!

I think I can safely assume that although there were signs from the latest mockup that suggested the design that was released today nobody really expected what came out to come out. Well, the final layout is out and recorded as per protocol in the WIPUP project. It can be seen in detail here. As usual the full project timeline can be seen in my WIPUP profile page.

Well, go check out the KDE.org website to see the real deal. For those interested in more details they can read the KDE Dot article about the relaunch. Pretty awesome, except that I was originally credited as "Doin Moult" (now fixed). Hopefully I should be poking my nose into more KDE www projects in the future.

Also happy to see a spike up to almost 1000 views in the past week of WIPUP updates. I know it’s unfinished and all, but I must say I quite like using the system. Perhaps in the future I should try out some other media types in my updates to see how well they fare.

Uncategorized

Countdown to KDE 4.4 and the new KDE website: 1 day left

The new KDE website redesign is due any day now (with the release of KDE SC 4.4) and when it’s released you will be able to see how ideas were amalgamated from many different mockups and some which I’ve not had the records to post. The final design is different, much more aligned with the KDE "Air" branding, and most importantly a shared effort, like what open-source is meant to be. So don’t be too shocked if what is released is completely different.

Check out the latest mockup update here.

Past mockups viewable in full on my WIPUP profile.

Uncategorized

Countdown to KDE 4.4 and the new KDE website: 2 days left

Only 2 days left until the KDE SC 4.4 is released, but apparently the website design is due out on the 8th! Yes, that’s tomorrow. Today’s update shows a stage in the mockup which is natural to designers – the rejection stage. A new idea (in this case, minimalism) is chosen and we try out something new to see if we like it.

View the full update here. Full progress can be seen on my WIPUP profile.