Our good friends over at LinkedIn have re-designed their website! Over the last couple of years, what started out as an experiment in social connectivity became the world’s leading business-oriented professional networking site. Although LinkedIn has always had a clean, uncluttered design that speaks for itself, it was probably about time for a little ‘Web 2′ face lift – and the new design definitely delivers.

So what has LinkedIn changed?

Top-level navigation:

The changes, as can be seen are quite substantial. Old-school tabs (which were nonetheless very usable), have been replaced with a ‘a la Facebook‘ style drop-down menu, which allows click-through for the parent pages. For example, clicking on ‘People’ above will take you to the ‘People’ main sub-page, while clicking on the arrow besides ‘People’ will allow you to jump to other subsequent pages belonging to the ‘People’ top-level menu. The navigation menu also follows through, throughout the site – something which is very important in information architecture and usability; and combined with the search bar in the same horizontal space, makes for a very-usable menu structure.

I think the top-level navigation is quite a big cleaner – with a lot more leaning towards a lot more whitespace – giving the website an open, dynamic feel.

Side-navigation & Widgets

The cool side of the new LinkedIn design includes changes to the way the user can interact with the website, and vice versa. The side navigation, which is clear, intuitive and flows throughout the website is dynamic – and more importantly allows the user to customise what menu options, i.e. ‘Groups’ or ‘Inbox’ they would like to me minimised or maximised, as they traverse the website. An example follows:

Finally, some cool social networking features. Firstly, as can be seen above, there is a new ‘What are you working on?’ feature. Relative to Facebook‘s status message(s), this handy little feature will broadcast your ‘status’ to yourconnections as a network update and will – as expected, appear as a new element on the profile page. Following in Facebook’s footsteps, LinkedIn let’s you control your status’ visibility and whether you want to see other peoples’ status in your network updates feed. And example follows:

Another new addition to the ranks on LinkedIn’s re-design are cool widgets (which LinkedIn will apparently be releasing more of!) that sit in the right-hand sidebar. They can be dragged-and-dropped into position and feature such information such as: Your profile snapshot (views, how many times you have appeared in search results, etc), as well as Q&A from the network, and finally jobs, and other links. Clicking on ‘edit’ as seen below, gives the user options that can be changed for that particular ‘widget’. For example, clicking ‘edit’ on the “Answers” widget, let’s you select what search answers category you would like – from a drop-down.

Let’s take a look at some other visual/functional comparisons.

The old LinkedIn contacts page:

The new LinkedIn contacts page:

The old LinkedIn (logged in) homepage:

The new LinkedIn (logged in) homepage:

So there you have it! The new LinkedIn homepage and review of a brand spankin’ new feature-set. Overall, I think the site is very usable, and more importantly, user-friendly. However, nothing is ever going to be 100% – and there are little quirks.

When JavaScript is disabled, as imagined, not many features are still usable. For example, the widgets are now gone, and you can’t even minimise/maximise your left-hand navigation! I mean hat’s off to LinkedIn for a great re-design, but I’m sure it would not have been hard to make a degradable-version of the website for when JavaScript is disabled or turned off (for whatever reason!). However, to LinkedIn’s defense, many important functions such as ‘Contacts’ page do have a ‘basic connection browser’ that whilst looking archaic, got the job done; which I thought was admirable!

There were also a few things that LinkedIn could work on to add that extra bit of professionalism to the site, and they include little things like making sure there aren’t too many different styles representing many of the same things; such as font/typeface choices on the interface – which seemed like ‘a bit of everything’. Adding onto that were very-minor things such as inconsistencies with buttons. Once again, all these things are very minor – and sometimes a consistent user experience comes second to the visual weighting and importance that colour and style bring to navigational/interface items.

A great design, from a great website!

So what do you think? Please leave any comments you may have – hate it? love it? Let the community know – and be sure to sign up to the RSS feed for more updates on when we post a new article.

The keyword reach associated with building a website is limitless, but essentially – as ghastly as it might sound; building a website without planning, can – and most of the time will mean danger ahead and ultimately less success in the long run!

So without further ado, here is Cheb’s guide to building a successful website.

Planning/Scoping

The “Ahh, guys? What are we building again?” phase

So, you want to build a website? It’s not rocket science – but it is a science, and an art! Just like baking a cake you have several ingredients: A handful of designs, a dash of slicing, a teaspoon of code, a sprinkle of love, and ‘bob’s your uncle’ – or, ahh, not! What many people in the web industry however don’t realise is that the planning phase of a website is so crucial, that it really can dictate how well the build of the website is. Essentially, if done correctly, the planning phase – or more importantly, the scoping sub-set of the planning phase, should setup the site’s structure, navigation, as well as functional specifications for the web site build.

Scoping (also referred to as Information Architecture) should reveal not only the clients’ objectives for the project and what they would like the site to achieve – but more importantly, extrapolate all the detail, business rules, as well as technical adjustments which will be needed down the track in order to successfully design, build and launch the website.

Without mentioning any names, I’ve worked with around six web firms, in some way or another, in Australia alone – and the sad thing is, only 65% of them actually ‘recognised’ the importance of getting scoping/Information architecture right! Obviously Wiliam Web Design is in the 65 percent that got it right! Overall though, not really the statistics you’d like in the field of web design and development – right?

At the risk of helping the competition too much – to be counted up with the ‘best of the best’ you’d be expecting your Information Architects/Business Analysts/Usability Evangelists/whatever you want to call them – to be able to at least come up with the following pieces of documentation in this phase of the web build. As a side note, the documents listed below will be discussed in detail in an upcoming post so stay tuned!

1. Requirements gathering documentation
2. Requirements analysis documentation
3. Functional specification documentation
4. Prototype development

You read it here first ladies and gentlemen! From this day forward, let it be known that Cheb D coined the term “The GASP Method for scoping/information architecture” which will be used to outline the bare minimum in terms of documentation/deliverables; that the planning/scoping phase of a good website build whether in Sydney, Melbourne, New York, or London – should deliver. I will outline the massive importance that these documents play in the successful build of a website in an upcoming post – for now, let’s kick on to design.

Design

The “Wow! so all you needed was good documentation and you came up with THAT?!?” phase

Never thought this would be a part of this post, yeh? Okay, so nothing overly-crazy here. You can’t build a website without design. The situation is that everything that happens from this point forward will start to effect everything else throughout the project. Think of it as the literal view of ‘The Waterfall Model‘ for software development.

Further to that – everything that was done right in the previous phase will already have a dramatic affect on the project as a whole, because the difference between a good and bad design decision does not always start and end with the designer! Whether you are building a web design blog or an E-Commerce shop-front, I think that holds true.

Designers as a collective, love to think that they understand everything about usability simply because they know good design! Sure, they would be one of the few people involved in the web design process who could have a say in how and why things will work – but having a designer nutting out the usability of their website as well as designing it, without the assistance of:

a) an objective individual such as an Information architect, and
b) an objective individual such as an Information architect with previous experience in online user experience design (UXD)/User interface design (UID), or usability and accessibility analysis;

is comparable to getting a developer to bug-check his own code or bombing for peace!! Good luck with that!

The issue however is that we have come to realise that good design is not necessarily always good usability, and more importantly that good design practices is not the same as usability. Something as simple as having a login box pop-up as a div overlay upon click, as apposed to always being on the page and distracting the user from more important areas of the page, such as a call to action – can be a big talking point.

It’s a double-edged sword! Do you hide the login box to begin with under a ‘login button’, or do you go with the norm and leave it showing on the front page, but risk it being a total distraction due to its positioning? A question that a designer shouldn’t have to, and probably can’t figure out on their own without some interaction from an information architect.

There is absolutely no doubt though how important this phase is in a good website build! It’s paramount that design is not only up to standard, but that is ‘sets’ the standard! New techniques, interactions as well as connectives to modern technologies such as Ajax should all be encouraged and not frowned upon as ‘making more work for developers’.

Slicing

The “Do you seriously expect me to cut this PSD up for you in THAT many hours ONLY?!?!?” phase

Slicing is one of those things that in the past has taught me can greatly change how upper management think about the whole design process. Some managers think the hours dedicated to it are way too much, others think that’s just unscrupulous and without merit that it ‘generally’ is allocated the least amount of hours dedicated to it out of the whole web site design build process.

Which ever way we look at it, years of experience has taught me that not only are designers getting ‘crazier’ with rounded-corners, drop-shadows, beveled-edges and more; but Web 2.0 calls for all that snazzy stuff, and unfortunately, I don’t see that stopping, coupled with, we can’t stop technology – means we have to find a half-way house!

I personally think more time needs to be dedicated as a whole to the slicing process. Not only do slicers need to give the PSD (design) some life using CSS and JavaScript, on top of HTML – but cross-browser testing is a freaking arduous and taxing process – if nothing else! So respect to all you slicers, or Interface Hackers as I like to call them… I feel your pain!

Development

The “Okay, so I take the source files from here, and connect it to WHICH database?” phase

Development and slicing somewhat go hand in hand.. Whether the web site is being developed in C# (.Net), PHP, Ruby on Rails, or Perl for that matter – the task is simple and complex – or better yet, simply-complex!

This phase is important and hence why most of the time, you will find a good chunk of the hours allocated to a web-based build will be allocated to development. Unfortunately, that’s the nature of code! What you want to do, is make sure that there are adequate hours for the design and slicing – but ultimately, depending on the scope, budget and size of the project, actual development of the sever-side application as well as all the database connectivity as such should be the biggest chunk of the collective ‘development/build’ pie.

Obviously, if the project is just design and slice, then there’d be no time against development phase, or minimal (for testing, etc).

Testing/Quality Assurance

The “Yikes… You found HOW MANY bugs?” phase

It’s not easy to fight technology. Somehow, no matter how hard we try, Testing and quality assurance will (unfortunately?) always be a phase in the successful build of a website. To aid in keeping this short(er) than I expect it to be, I would just make the following suggestions in dealing with this phase.

1. Make sure the project plan/milestone outline clearly shows the testing phase as part of the project (from the get go!). This is important because the client has to realise that no matter what happens during the life cycle of the web build, how fast the build is, how many functions they take out, or whatever it may be – this phase is not going anywhere!

2. Treat it like you would any other phase. You wouldn’t get your delivery man to code your website, would you? Don’t get your secretary or janitor to ‘run through the site and tell you if they find anything out of place’. Believe me, it is sad but trust me – I heard that statement being said about two years ago and it’s been ringing in my ears ever since! Pay for a tester, they are worth the dollars you spend on them! and finally,

3. Make sure the quality assurance/testing is being done off a functional specification! For god’s sake people! Cardinal rule of unit/website testing. Go in there with a plan! Do NOT just pretend you are a user and ‘click around’. In my experience, around 60% of bugs found in this phase are always business rules that either the tester didn’t know about, or were simply forgotten. If they are on a document that has a signature on it, it WILL save your behind!

Deployment/Launch

The “So does that mean we can get paid now?” phase

Website design and development; once again, whether in Sydney, Australia or Sidney, Montana, USA – even though sadly many people don’t see it that way, is really an art. Wiliam has definitely set a precedent (and a name!) in the web design industry in Australia for not only delivering websites that work, but delivering websites that work great, and boy is that not a cliche!

It’s really about how you learn from your mistakes, co-ordinate change management in an ever-growing industry, and more importantly control technology that will ultimately dictate how you represent yourself as a web design agency/freelance web builder and best of all, how your competition view you in such a bloody competitive market.

So we’ve made it all this way. Launch the bugger! You’ve come all this way though and apparently you’ve survived. Don’t lose it all now! You want to make sure you take your time to get the launch right. Just like a top-secret launch sequence, make sure testing is complete, you have document listing where everything should go (server wise) – your databases are working fine and everything is connecting to where it should be – and then hit the switch!

Damn, wait.. Did you kill something? refresh, clear cache, refresh again, is it all still up? post to that forum that you created; is it threading correctly? Point is, make sure it doesn’t just stop when the last file is transferred. Building a great website involves a lot of co-operation from many people. It won’t happen overnight. Heck, sometimes it won’t happen over a six month period; but when you get it right? It’s a feeling like no other – or at least you’d hope so!

And that’s just about it… Happy web building people!

So, that was a long one. What are your thoughts? Do you agree on this model for effective website/web page design? let us know. Please drop a comment or if you like the posts, subscribe to our RSS feed to be alerted whenever a new post is available.

For those of us that are involved with design for the web on a daily basis, there seem to be many ways of creative navigation for websites that we come across. Over the last nine years or so on my journey designing for the world wide web, what I have noticed is that not only have conventions and ‘acceptable methodology’ changed on a regular basis – but also, the way some (big) site’s are architectured these days leave something to be imagined.

So without further ado; below are five reasons why I love tabbed navigation.

1. Tabs are an easy-to-setup form of navigation that don’t need to weigh down the load time of a website.

Whether it is CSS-based cross-browser accessible code or a simple unordered list, tabs are fairly easy to setup and re-use. The web design community is always coming up with solutions after solutions. A great example of accessible CSS-based tabs by Joshua Kaufman can be found here.

It’s also great to know that apart from the Web 1.0, standard text-based links, CSS-based tabs can now be done without any CSS hacks, with less code and the best part – without imagery; A formula for success.

2. Tabs are no supernatural phenomenon to not-so-techy web users.

Tabs are not just seen on the World Wide Web. They have been used for an incredibly long time. In fact, the reason why web user’s seem to get on like a house on fire with tabbed navigation is because they ‘know’ instinctively what they are supposed to do. Foldering systems, hanging-file folder tabs, as well the uber-cliched Inspector-Cluso style murder-mystery case files all have helped users to understand and appreciate the value of tabbed navigation on the Internet.

3. Tabs are very Web 2.0 and if coded correctly using XHTML lists, are fully W3C compliant forms of navigation

Gone are the days where 59Kb worth of images were needed to create tabs. These days, Web 2 techno’s like Ajax and even old-school style DHTML can spit out tabs that not only work well, but are 1000% W3C compliant. Sick!

4. Tabs are aesthetically pleasing to look at

Some would say, tabs for navigation also greatly aid in the representation of the overall look of a website. In all seriousness, I really dig how well-designed tabs can change the look of a site – completely. I really think there is something to tabs that not only make the user experience that little bit better, but also easier on the eyes than old-school list-based (yet accessible) non-tabs naviation. And last but not least:

5. Tabs are a collective norm these days in terms of navigational structures

Unless you have lived on the moon or under a rock for the past century, if done correctly, anyone is capable of understanding a website’s structure and information architecture from tabbed navigation. It’s the way to go in my opinion and best of all, you know that you are not re-creating the wheel if you use tabs – because there are not only hundreds of examples you can find online – but people still find it hard to believe that there are ways to create tab-based nav that don’t have to look 10 years old, or like Joe Blo’s tab system from across the information superhighway. Stay tuned because some of those ideas will be discussed in an upcoming blog!

So what do you think about this whole ‘tabulacious’ tabs for navigation? Do you currently use tabs on your site? Do you want to? Do you even like tabs? Share your opinions with the rest of the web world.