Google Chrome decides to render CSS before the page has finished loading it’s content. Therefore, if you’re wondering why paragraphs that AREN’T empty aren’t showing up, this could be why.

Other browsers render the content fine, just for the record. Probably because they do things logically, like load the DOM and the content before loading and rendering the CSS. Bit stupid really.

I signed up for their (gs) Grid Service package just over a month ago, and no matter what I try, it takes FOREVER to do anything via FTP. Or SFTP. It makes no difference what settings I try, it takes at least 1 second (on a 50mbps fibre-optic line, no less) to transfer / modify / delete a 4kb file.

Maintenance too… It seems to occur almost daily on one part or another of their infrastructure. For a company that puts across reliability and uptime as two of it’s main selling points, they seem to be offline an awful lot.

I’m moving to webfusion already, I’ve had enough of the slowness. If you’re looking for reliable, professional shared hosting, steer clear of MediaTemple is the only advice I can give!

I’ve been an avid Android fanboy since I first got earshot of it back in 2009. I follow technology news blogs such as Engadget and Gizmodo (which is basically just a 10-minutes-later Engadget recycler) and was constantly in love with how they looked, how they worked, and most importantly – how they were considered to be better than the iPhone.

Let’s cut to the chase here on why I became one of these snobby “I don’t want an iPhone” Android-lover guys. I’m a geek at heart. A true geek. The kind of geek who loved finding out how hackers could hack, who had an unhealthy interest in how programs actually became programs (yes, programs, not apps) and the languages they were written in. The kind of guy who would spend hours upon hours reading about pointless, mundane topics that would serve little to no purpose in life other than being able to say that you know about them instead of studying for my exams or writing up my coursework.

Those kinds of geeks like the best of the best. When the iPhone came out, it wasn’t the best of the best. It did what it was supposed to do, in a very fancy, sexy manner. But it wasn’t the best specification of phone on the market. This is why it wasn’t good enough for me. I’m probably coming across as being a little bit pretentious here, and I guess that’s the one of the points of this article. A lot of the people out there who are still using an Android phone are not using it for the same reasons they might initially have obtained one for.

iPhones up to the 3Gs were of a lower spec (examples to illustrate:- screen resolution, screen quality, processor speed, RAM availability, storage expansion, camera quality), weren’t open, were proprietary. This now is no longer the case. Look at the iPhone 4; it has the best screen resolution on the market, one of the best cameras on the market (and a front-facing camera thrown in), the most user-friendly and consistent UI on the market, the largest app inventory on the market, the most supported web browser on the market… The list could go on. The point I’m trying to make is possibly something Apple already mentioned when they released the damn thing (granted they need to crawl out of their behinds slightly on the ‘bigging ones’ self up’-ness) – “This changes everything. Again.” Because it does! There’s no denying it. What has Android got on the iPhone now? Seriously?

Okay, maybe I’m getting a little carried away with myself. I know Android still has a few one-ups on the iPhone, for things that the iPhone simply will never have, like a full Google Maps suite (by that I mean the fancy-pants turn-by-turn Navigation, I love it), Google Mail and Account sync (it works perfectly for me, since I’m a 6-year-strong everything-Google lover), and of course the thing that every programmer loves – openness.

However, seeing as I never program (and despite having the desire to, I probably never will do either due to wanting to become a master of one trade, not of many), this whole openness thing Google are playing on doesn’t really inspire me to stick with ‘em.

By the time I come to upgrade (March 2012), there’ll undoubtably have been another iPhone been released, and a multitude of swanky new Android devices that’ll have tickled my fancy. But unless Android steps up the game and starts to provide a much more consistent framework in the system menus and inner workings across their entire suite of apps (like Apple has managed to maintain oh-so-well with their strict app building rules and SDKs), then I’ll be moving away from the Android gang. Google Mail and Accounts sync is a small sacrifice to make when I use my mobile phone for pretty much everything else, every day of the year, wherever I am. Apple does it right – simple as, mate.

I decided this needed to be documented, since I’ve learned a process of designing in such a manner that IE6 doesn’t always have to be that ball-ache at the end of a project!

There are a few common practices I’ve begun to follow that can cut out a lot of the bug-fixing you inherently brace yourself for once a site is ‘complete’ in all other browsers. I worked these out over the last two projects I’ve worked on, which incidentally were both designed ‘in browser’ using Andy Clarke‘s Hardboiled methodology.

Before I go into specifics, note that I’m aware these may not necessarily be the best practices for your web site, and that everyone’s preferences for bug-fixing in IE are different. These are just the ones I use, and know to work every time!

display:inline; float:left;

This one’s the most important of all, in my opinion. It reduces the need for other ‘hacky’ CSS fixes that force a box model, such as ‘height:1%;’ or ‘zoom:1;’. Apply this to all container elements (e.g. DIVs, ULs), and anything else you may encounter box model issues with. They’ll express the exact same positioning behaviour in IE as they do in other browsers, if you globally apply these styles to your elements.

Always apply margin/padding to internal elements, not to containers

I’m aware there’ll always be exceptions to this rule, but to save yourself a great deal of headaches and IE conditional-commented CSS rewriting, follow this rule.

I usually give the containers specified widths with no padding or margin, then apply those spacing values to all of their internal elements. If this seems like too much of a hassle though, for example if there’s going to be many different types of elements inside this container, there’s an alternative route – embed another ‘inner’ container inside of the one you specified a width to. Give this container the necessary margin or padding, but don’t give it a width, and don’t give it a float. This way the contents will naturally span the width of the outer container, but have that left or right margin or padding applied.

I shared company with my fellow web development folk of Jadu, the organisation from whence I hail. Upon my return from the two-day conference, I went straight to work on writing up my notes from the presentations I’d attended, initially to share the wealth of information I’d gathered with the rest of my colleagues – however, I’ve decided now to also share said write-up on here, too. So here it is.

Designing for play – Christian Crumlish

Christian provided to us a very engaging presentation on how to design for social engagement. His slides were divided up into very modular sections, giving us more of a bullet-point approach to take notes from rather than speaking to us a story.

A lot of what he was trying to put across to us was that users enjoy being able to use websites naturally. When needing to represent themselves in some form or another to others within the same platform, they expect to be able to do so (through means of an avatar, for example). They expect sites to flow, for things to be obvious, and to enjoy their experience. Christian used examples of actual games (board games, video games, and to prove his points further, even musical instruments) throughout the presentation to compare relative experiences on websites, and how particular features (when implemented correctly) will make a successful website.

One great example he gave was with actual social websites and how they are experienced, particularly Facebook and MySpace. The former of the two utilises one key feature, and that is a strict framework. When designing a website that has the potential to get very out of hand through user input and customisation (personalising user profiles, for example), strict frameworks need to be put into place. Facebook’s framework prohibits any user from customising the “look and feel” of their profile page, hence keeping everything neat, tidy and uniform. MySpace on the other hand became renowned for providing the exact opposite to its users, and actually won over many of its younger generation for this reason alone. However, this led to chaos (profiles that looked hideous and unreadable/unusable), and users slowly but surely moved towards the more ‘stable’ of the two networking platforms – leaving MySpace with minimal actual users, and becoming more of a music/band orientated site.

Another of the reasons he gave as to why Facebook is such a successful (perhaps THE MOST successful) site of its kind was that it allows users to make mistakes, but still able to make those mistakes work. Take for example a new user to the site, inexperienced to social networking, not knowing where to start or what to do. They are greeted with a tutorial on how to set up their profile and enter their personal information – great, easy, done. What next? They see the ‘Home screen’ and news feed, and a great big text box at the top asking “What’s on your mind?”. You write what is on your mind, and post it. You then proceed to a friends’ profile page, and see a similarly styled great big text box at the top, this time saying “Write something…”. Without navigating back to the home screen, the user may wish to write something else that is on their mind, and not realise it is going directly to that person… A mistake has been made. But did the website break? Was their experience destroyed? No. The person they left their message upon responds with a ‘comment’, explaining the error of their ways, and the user has learned something new – whilst at the same time, communicating with a friend and in turn, being socially engaged.

It is this aspect that leads to a sense of play, an invitation to make more mistakes and still feel comfortable. The experience can be compared to the aforementioned aspect of playing an instrument. Christian told us of learning to play the ukulele, and although once in a while he would hit the wrong string whilst playing a chord (making a mistake), it would still sound great, and so he would continue make the same mistake again, rather next time it would be intentional.

I think overall, the biggest part of what I took away from this presentation was that you have to ensure a website flows. Design flaws can be instantly spotted when this doesn’t happen, and the phrase “Don’t make me think!” is what first comes to my mind when trying to envision the success of a socially-interactive website design.

An introduction to server-side JavaScript – Tom Hughes-Croucher

Otherwise known as SSJS, server-side JavaScript got me pretty excited after hearing this talk. Tom was quite a character, firstly pointing out his “American transformation” with the crazy glove-shoes he was rocking, and of course his tinged English accent from living the Californian life for the past 2 years.

He started off his presentation by stating that the remainder of his slides will be shown in Comic Sans. “I know, I know.” he said, as we all rolled our eyes. “I can guarantee though, that you still won’t hate me. This is so awesome, and I am so confident that you’ll think the same, that even Comic Sans won’t bring you down.” From this point on, I knew we’d be getting some more laughs out of him. And we did. (You had to be there.)

-This is where it gets geeky-

Right now, there are no “official” standards for server-side JavaScript, as the official JavaScript specification only gives APIs that are useful for browser-based applications. Therefore, something called CommonJS got invented, which is basically a super-fast object-oriented API, providing APIs that ARE useful for SSJS, also allowing the developers’ applications the freedom to work across multiple platforms (V8, Rhino etc.)

Direct from the CommonJS website, its most notable benefits of use are:

• Server-side JavaScript applications
• Command line tools
• Desktop GUI-based applications
• Hybrid applications (Titanium, Adobe AIR)

Tom swiftly brushed over this though, mentioning to us a little known gold-mine to SSJS’ers – that being Node.js. Apparently this is the greatest thing ever, and gets lots of JavaScript programmers very excited. I personally just enjoyed watching his enthusiasm as he went through bits of code (not understanding 95% of what he was showing us), it was still interesting. From what I gathered (I shall research this more when I get the chance to), Node.js does everything. It can be installed to a Unix server using just 4 lines of code, and is capable of running queries 10-to-the-6 times faster than Apache can (or so he claims). It is also capable of rendering a scripts’ HTML and DOM on the server, allowing applications to run lightning fast when, say, a AJAX request is sent to the server for a content change or something.

All in all, very interesting. And he was right – it certainly did leave me thinking it was awesome.

The Art of emotional design – Aral Balkan

I think this talk could be compared to Marmite. Personally I enjoyed it, a lot, although my team leader was not so keen (for whatever reason). It gave me an insight into how great an application (web or mobile) can actually be, if it is thought out well enough and no expense is spared in the effort and passion put into its development.

The majority of his presentation consisted of him showing us how he developed his latest iPhone app, namely “Feathers”. It was a very simple idea in context, basically allowing the user to ‘jazz up’ their tweets through use of special Unicode characters, etc. However, him being the perfectionist that he is, and having the mindset that he has toward user experience and how essential it is to put across a ‘good’ one to your user, the application he produced absolutely shone.

Aral gave us numerous examples of situations we, as designers (and developers, no less), should put ourselves into when we’re creating our applications or websites. He asked us at one point to close our eyes, and remember back to when we felt a real, genuine sense of delight. That glee, that happiness, that pure excitement about something that you only feel several times throughout your entire life. For mine, I remembered back to when I was having my final interview at Jadu, and the CEO came and told me I’d gotten the job. That feeling, right there.

He then told us to hold that memory in our minds, that sense of delight, and settle on nothing short of an experience to our end-users of whatever application we were creating. A magical experience, if you will. He told us that a very reputable organisation who shall not be named (*cough* APPLE *cough*), were highly renowned for perfecting this experience in every product they release.

Through providing products that ensure this magical experience to their end users, they are able to ‘reinvent’ already successful product genres with their own take – examples being the mp3 player with the iPod, the home computer with the iMac, the mobile phone with the iPhone, the netbook/e-reader with the iPad. I think this proves his point entirely!

I know I’ve only covered three of the many presentations I attended over the span of those two days, but they are the ones that really stood out to me, and I feel have had the most effect on how I will design (and develop) my sites from this point on.

Would just like to usher my thanks to all of the speakers whose talks I made notes on – you’ve definitely helped aid my path to becoming one of ‘the best’!

As much as you’d like to believe it, design does not come naturally. It needs to be learned. I’m lucky enough to have a peer that has been taught a hell of a lot, and has been patient enough with me to give me chances to improve what I do, and learn through my mistakes.

The site I am in the process of designing is for a large public-facing client. They want something that is “clean, organised, and modern”. The first round of design that was so close to being finalised on my side (not yet seen by the client), was actually a complete state – simply because I’d become oblivious to its flaws. Padding was inconsistent, headings were inconsistent, weights and colours of typography and containers were inconsistent, font usage was inconsistent. But how was it this bad without me even noticing? One reason – I’d focused my design around one main feature, and NOT looked at the bigger picture.

The feature I speak of was a large horizontal accordion. Having recently read a blog post entitled something along the lines of “Design trends of 2010″, and seeing horizontal accordions on the list, I thought I’d try my dab-hand at something a little bit different. Horizontal accordions are (in my mind) clean, modern, and keep content organised – all whilst looking pretty damn sexy. So at wireframe stage, I pushed most the design that featured the accordion. I really pushed it. As it turns out, they still preferred the simple tabbed carousel option so chose that one instead, but having been set a tight design schedule I decided to start Photoshopping early, even before they’d even agreed to a wireframe. This accordion was the feature I’d focused all my attention on – I wanted it to shine, and so designed this first and built the rest of the site around it.

So what should I have done instead? After a good hour’s chat with my peer, and a cram-session of being shown techniques and methods of designing in Photoshop that I was completely unaware of, I think I may be set on the right path again.

Start off in black and white. This way, you can focus PURELY on the basics – layout, weights, fonts (this is still perhaps jumping too far ahead), padding. These are the things that are key to the success of a design. Forget colour, forget images, forget icons; all of those are things that you’ll spend way too much time mulling over and will become that feature you unknowingly build the rest of your site around, then wonder why you hit a brick wall two or three days later!

Starting off in black and white might seem like the logical thing to do, but for me, I always just dove straight in with the colours and the fonts and just arranged the elements in a way that I thought worked. It may have been successful once in a blue moon, but not for sites that have the potential to grow (i.e. those powered by CMS) – which in essence, the majority of sites I design for now, do. This isn’t wireframing, it’s one step beyond that. Wireframing is a rough sketch, this is the beginning of a design. It’s the foundations on which you will build upon. Get this bit right, you’ll save yourself so much frustration further down the line.

Alternatively, do what I did which was ignore the advice, dive straight in and try to get all the design elements down at the start. You’ll either end up with a mess, or having to start again.

I’m sure something similar has happened to every designer at some point early on in their career, it’s no doubt part of starting out in the big wide world of design. You need to learn to follow the right process. But I’ve had to experience it (more than once) to know that unless you tell yourself you’re doing it, and stop yourself from continuing to do so, it’ll keep on happening. I’ve had to scrap pretty much everything I did because I designed a whole site around one feature on a homepage.