The conference, put on by Aral Balkan, was fantastic. I finally got to meet Sarah Parmenter, Jeremy Keith, Geri Coady and Remy Sharp. I also made some new friends, Laura Kalbag and Scott Coello. I also enjoyed seeing the Clearleft office in person and having a long tea break discussing politics and religion with Aral.

I do admit that I missed the first set of talks due to the airline “forgetting” to put some luggage on the plane and the hubby not having anything to wear. Luckily, we made it there by the first break.

Let’s get started on the talks, shall we?

One Web by Jeremy Keith

I’ve read a lot of books by Jeremy, but never heard him speak until this conference. The man is as stubborn and loud as me and I loved it. His talk was very passionate and I was able to follow along. At one point, he even called iOS developers “fucking peasants”. It was fantastic.

Jeremy stated that the web was created to be open, and unlike anything else, you didn’t need permission from anyone to create content on it and that anything could be published. The links were open and you could link from one site to another without asking anyone for permission. The internet’s primary design was universality and was meant to be used on any device or with any handicap.

The problem with native app design is that it takes us back 20 years before the web was born. Native apps may be great, but how long will those resources lasts? When you create content on the web, it lasts for forever, as long as you pay for hosting, but it’s harder to keep content alive when it’s tied to a specific device. All a web needs is HTML, HTTP and a URL.

Back when the web was new, it’s competition came from CD-ROMs like Microsoft Incarta, but the web was able to succeed because of the links and it’s updatability. Today’s competition comes from apps, but it can be argued that because of links, web is really the “killer app”.

The internet is real time communication and it threatens publishers and content controllers like magazines, news providers, music and film makers because it allows anyone to publish. These outlets are excited about the popularity of native apps because it brings back control and exclusivity.

What is the web for? For for fun? For users? Merely to make money (which Jeremy argued, is no better than a prostitute)? The web is meant for humans in order to contribute to a better world.

Steve Jobs once said that you don’t need to be permission to be awesome – but you do with native apps.

Geek Ninja Battle – or Jeremy Keith vs. Everyone Else

This WAS the best talk of all, which was more like a debate between Jeremy Keith and everyone else on the panel. The other members were Aral, Kevin, Martin, Matt and Seb. Basically, the battle was about which is better, native or web apps. Jeremy being a hardcore web-only kind of guy, basically ended up arguing with everyone, especially Aral, and there was seriously a part where I though punches were about to be thrown. It truly was a battle and quite entertaining (and informative of course). It’s interesting to see how we all geek out over little stuff like this that the rest of the world never thinks or cares about.

Aral asked Martin, who works at Microsoft, why we should use their new Windows phone. Honestly, I thought the guy gave a pretty weak answer, which basically boiled down to “you can build apps quickly and we’re a big company”…riiiight…..

Matt, and iOS developer, thought it was important to just make the commitment to get something out and that it was more about delivery than the type of platform you used. He cited the example about how when you subscribe to a newspaper on the Kindle, it’s automatically delivered every morning.

Kevin, a Titanium developer, suggested that native was better, because in web it’s difficult to integrate with the phone’s system and all of its features. He suggested using something like Titanium, which is a cross-platform tool and allows you to be more productive by creating one app for all platforms.

Jeremy Keith said it was important to not focus on one platform and limit your user base, but to create a progressive website that can be accessed by everyone, even crappy browsers (at this, he pointed to Martin, the Microsoft guy). Jeremy said that by creating a baseline that worked for all devices and browsers and then enhancing it for a few, it gave you a competitive advantage against those that created an app for only a select few. He also stated that what you’re getting natively on apps now, is what will soon be the future of the web. He also stated that we need to stop trying to make web apps look native, in order to avoid confusion.

Seb agreed with Jeremy Keith’s view that progressive enhancement was a great tool for mobile, but that it’s limited and not for interactive apps.

At this point, it was less about questions from Aral, and more about a huge debate between Jeremy and everyone else. Aral and Jeremy debated about optimising for features, not devices, to which Jeremy disagreed with both. Aral brought up the issue of making money from web apps, which is not as easy to do as native apps are. Jeremy stated that making money this way is outdated. Not sure how I feel about that!

Angry Exorcist – Seb Ly Delisle

This talk was a step-by-step on how to make an Angry Birds clone in under 30 minutes using the Corona SDK. You can find the source code at Seb’s website and follow Seb on Twitter to find out more about this hilarious project. Hopefully, he’ll post a video of how he did it, it was fantastic!

Design Challenges – Sarah Parmenter

Sarah Parmenter laid out 10 design challenges that you’ll face as an iOS designer.

1. Fluid design – She stated how important it was to make sure your designs are able to be stretched and to watch out for gradients and the slicing of buttons and background elements.
2. Use familiar behaviors – A great touch reference can be found at Luke W’s website.
3. Clean up your environment – Properly name your groups and layers, keep folders neat and keep a scratch folder for all the elements developer’s will need, like buttons.
4. Progressive disclosure – Hide actions that don’t need to be shown. Clients often don’t like this, but users do. For example, the pull down to refresh action.
5. Tap targets – Make sure they’re big enough for fingers to push without accidentally hitting something else. The minimum hit target is 44×22 pixels.
6. Orientations – Users have a preference for using either landscape or portrait, so don’t force them to use one or another. Make sure your app is flexible and can adapt. A popular layout technique is using 3 columns in landscape mode and 2 in portrait.
7. Keep designs relevant to its OS.
8. Beyond human interface guides – Know the limits of the OS, even the smallest actions and gestures matter.
9. Retina display – Don’t ignore the retina display, it only takes basic math to do. A trick is to use shapes in Photoshop, as this allows you to resize the PSD easily without distorting it.
10. Automator – There’s an add on you can find online for adding the suffix to the file for the retina display to work.

Arse Over Tit or “How designers/developers have perfected the art of making things backwards” – Relly

I wasn’t too big a fan of this talk, I’m not really interested too much in content myself and Relly talked much too quickly so it was really hard to understand her.

Relly noted that content strategists normally don’t come into a project until the end. She asked, “What if books were made like apps?” You would first decide to make a book, choose a format, design a cover, pick out fonts, figure out the type of paper you’d want to use, pick a title….and then come up with the subject and content of the actual book??

You can’t make a hit app, but you can think up a plan for one. You’re only as good as the components you make and writing doesn’t scale. Relly suggested breaking up the large content projects into smaller pieces in order to get through them. She reminded us that the plan is not the work.

Ronald Wayne

Apparently there’s a third founder of Apple–I didn’t know that, did you? He met Steve Jobs while working at Atari (and Steve wrote my favorite game, Breakout). Ronald has never owned any Apple product, so he was present with an iPad 2 by the Update crew.

“We are designing for humans and they are central to what we do”

Beyond Delicious – Joachim Bondo

Delicious apps are those that devs put extra work into the UI. They’re the apps that users recommend, love and purchase.

1. Make code more beautiful than the UI. Delicious apps go beyond skin deep and into the code.
2. Under-state, Over-deliver.  Move focus from the user interface to the user experience.
3. Quality takes time. Respect users by taking your time in development.

The Digital Nature – Anna Debenham

Studies show that students who use tech are better with their studies. Unfortunately, schools are more likely to over-monitor the students. For example, a teacher couldn’t show his students the “view source” feature in the student library  because it had been blocked by the school for “security risks”. Over monitoring of students pushes them to hack their way around the systems.

Computer science isn’t taught as a standard in the UK, instead they teach how to use the software, but not how it’s made. Interest in software development is lower than ever. Today’s software and hardware focuses on hiding its design, because it’s thought to be too scary for users.

You can view the slides of this talk at maban.co.uk/dn

Geek Ninja Battle 2 – Design Challenges

Consisted of Joachim, Cennydd, Relly, Sarah, Remy and Aral.

Aral asked, “What are some of the unique design challenges to mobile?” Sarah answered that less is more and you should try to strip out the process to only three or four screens to make it easier for the user. Cennydd asked, “What do you mean by mobile? It could be the property of the device or user. Is the person using his iPhone at home mobile, or is the person using his laptop on a train mobile?”

Aral then asked, “What about ergonomics then?” Cennydd replied that ergonomics are limited, there’s a big difference between touch screen and using a keyboard and mouse. Anything more than one touch on a real mobile user is difficult to do. Joachim said to always strive for simplicity. Only put five buttons or less in the toolbar (which is in the Apple user guide).

“What are some copy restrictions?”, Aral asked. Relly said that the “people don’t read” belief actually depends on the context. Consider what the main task of what they’re doing is and how to let them get to that chunk of information. Mobile is “not what we can cut out, but what makes the most sense” to show.

Aral turned to Remy and asked him what some of the development challenges were? Remy said that if the app isn’t designed to be on the desktop, then it’s designed to be mobile. He recommended using libraries like jQuery mobile for quicker developer, although he also suggested using barebones development. If he can use a library to accomplish what he’s doing quickly though, he’ll use that. Apps should be as small and lean as possible. Cennydd said context is king in theory, but difficult to figure out in reality. Only way to figure out is by extensive researching.

The Things of the Future – Cennydd  Bowles

Many of the things of today don’t do anything. We plan for obsolesce now and we create a lot of crap and artificial demand. We;ve become complacent and allow advertisers to talk to us like idiots, making a dilution of value.

The audience is changing, however, only 12% of consumers have high opinions of big business. People are now more connected and can find out the truth about your products easily. They’re no longer satisfied with the consumer role. The web builds societies, educates and frees us.

The things of the future will:

• Be human and consider how products talk with the user.
• Mobile phones will have sensory input
• More clues for designers to interact with
• Tackle wicked problems like energy consumption, health and financial management.
• Disrupt by uprooting existing way of doing things

Sites are now cross-channel where media, form and function are now separated. Users don’t see why they should be different from being in-store to on the web or in an app.

Designers should now forced to think about the entire lifestyle of an item and create fewer, better things.

Photos from the Update Conference & Royal Dinner

I again want to thank all of you who made it possible for me to come here! It was fantastic!

I’ve never been a big fan of video on the web either, since I’m never at my computer unless I’m working so I never have time to watch. However, upon learning that Think Vitamin created a new membership service, called Think Vitamin Membership, I was immediately interested.

Read the rest of my post on FreelanceFolder

Andy Clarke called me personally (yes called) to apologize for all the agony I’ve been through for being without Hardboiled. He’s a swell chap. He ended up personally sending me the PDF version of the book so I could finally get Hardboiled myself.

Anyways on to the book review…

The book wasn’t anything like I thought it was going to be. Many people on Twitter said it was a “huge” book and 400 pages long, so I thought it was going to be like AdvancED CSS, 400 pages of size 10 font with little to no images. However, Hardboiled wasn’t like that and it only took me a couple of days to get through. It was 400 pages, but most of the pages were taken up by full-colored images, illustrations, code and general font size and gutters. Nothing to be scared of here kiddies!

There are lots of things in Hardboiled Web Design for everyone. You’ve got HTML5, basic CSS3, ARIAs & microformats (two things I’ve never been interested in, I’m bad, I know) and CSS3 animations, transition and the such.

The book was great to read, and the detective theme was pretty enjoyable. Code is, after all, a bit dry to read about, so it’s nice to see that Andy took the extra step to spice it up so it didn’t sound like a college textbook.

There was one, and really only one, thing I was disappointed in. Personally, I’m a fan of making the sites look awesome in the best browsers, and degrade nicely in IE. Honestly, who cares if IE has rounded corners and drop shadows? Do the visitors actually ever miss anything? (They don’t, believe me. I’ve asked). Andy says he agrees with this, but then his reliance on a ton of Javascript makes me believe otherwise. I consider things like Modernizer and browser specific stylesheets to be akin to IE hacks. I know some developers disagree with this, but I’m a fan of clean code, and hacks just aren’t clean.

Now, I also don’t believe in the argument of “what if Javascript is turned off?”, as the average user doesn’t even know what Javascript is, so I’m not worried that Modernizer wouldn’t work or anything, I just don’t believe we should relay on JS so much. It’s slow, buggy and always adds a ton of extra code. Why not just leave IE alone?

One of the biggest examples of this was his multiple background area. When using multiple backgrounds, you can declare a regular background before the multiple background rule, and IE will read this and skip the multi rule. Instead of suggesting this (although Andy did point out in his showcase area that another person did this) he suggested using Modernizer to do this, which was like walking the opposite direction to get to your neighbor’s house.

Other than that though, the book was awesome and while there isn’t too much of HTML5 and CSS3 that I don’t already know, I still picked up a few tricks, learned a couple of new ways to make my code even cleaner and had a good laugh at all the private dicks illustrations. I give the book a good 4 out of 5 stars.

Good job Andy, and thanks again for personally calling me. That makes you a hero

Want to buy it?

Of course you do. Pick it up at the Hardboiled Web Design site!

Perhaps the guys who take care of the podcast aren’t coders, or aren’t front-end developers, and if that’s the case, then I forgive them for their validation transgressions. I just hope they really aren’t front-end developers…

What They Said

The guys at Sitepoint admitted they no longer validate their sites, and none of their sites could pass basic validation. They believed that because large sites like Google and Facebook didn’t validate, why should they? They then commented that validation is no longer important today.

Validation Is Important

I’ve always believed that validation is important, especially since I decided to focus my career on front-end development. Surprisingly, this is a source of a lot of debate in the development world, which makes about as much sense to me as policemen disregarding their standard rules.

Validation is written by the W3C, which takes care of HTML and CSS standards. Validation rules are like guidelines, you don’t have to do it, but it’s something you should do.

Passing validation helps in several ways – it helps you rule out browser bugs, your code tends to be cleaner in nature, and you help push a browser standard that will make it easier to code for in the future. Think about it – if developers didn’t care about following standards, why would browsers? We’d probably end up back in the Netscape/Internet Explorer days where each browser went off in their own direction in how they rendered items. It would be like hacking and coding for each browser – and we’re trying to move away from hacks right? (Which is why I’m holding off on using HTML5).

Plus it holds your code to a higher standard and shows you care about quality. Designers don’t have to use grids or good typography to make a living, both those that do are often more successful. The same with developers. I’ve actually had clients go through each of my portfolio pieces to see if they validated.

Validation Is More Important Than Ever

Not only has validation always been important, but it’s now more important than ever. Even though it can’t directly affect your SEO, getting rid of extra divs (divitis & semantics related to validation) allows the Google bot to make it through your code easier and ensures they capture all of your content.

With the proliferation of new kinds of browsers as well (think mobile, iPads & netbooks), validation becomes even more important. I just finished coding a huge mobile site for Audible and encountered several bugs invisible to Firefox and even the desktop version of Safari. Upon glancing at the iPhone, however, you could see huge layout issues. The problem was mismatched tags and improper nesting. Had I not gone and validated the site, I could’ve been searching for the bug for forever.

Resistence

I’ve never understood why a lot of developers never took the extra step to validate their HTML. A lot of the complaints I get about validating, is that it takes forever. However, it should easily take you less than five minutes to validate your code if you learn proper syntax and rules. It’s easy.

Of course, there are always exceptions to the rule. When a client insists on a new browser window popup on link, and for some reason you’re unable to use JS for this, you’ll often find yourself using target=_blank and that’s ok every once in awhile, although you should try to deter the client from new browser windows due to user annoyance.

I will admit that I don’t bother validating my CSS. Before CSS3 I never really had any CSS validation errors, and if I did it was easy to tell by the messed up website. Now that I use a lot of CSS3 and vendor prefixes, I don’t even bother to look. But these aren’t improper syntaxes or hacks – they’re still valid code.

Your Thoughts

Do you validate your code? Why or why not?

Unlike HTML and CSS, it’s a bit tougher to jump into back-end languages and “just get started”. It’s not as easy as hitting “view source” on a site you like and using firebug to figure out how to manipulate things and what does what. Just like learning a new speaking language, it takes a lot of work and practice. The hardest part though, is simply figure out how and where to start.

If You’re New To Development

If you think CSS is a secret government agency and you’ve never ever seen an HTML tag, it’s probably better to start at the basics. Even if you’re planning on being a PHP or Objective-C developer, in order to being understanding code and how it affects what you see, it’s better to start at the beginning – with HTML and CSS.

HTML and CSS are easy enough to learn the basics on your own without anything other than a simple text editor (Like Textpad that comes with your computer) and access to the web. Luckily enough for you, you don’t even need any file transfer software because you can build simple HTML sites and view them off the web in your browser!

I don’t recommend getting an HTML/CSS book, as it’s pretty easy to learn on your own. Copy the HTML from your favorite site, paste it into your text area and look at the code. The cool thing about HTML, is that everything is pretty obviously as to what it is. a <p> is a paragraph, a <div> is a division or block of space, etc etc. Starting changing the code, save it and look at what happens in the browser. How do you move stuff? What breaks?

And remember, Google is ALWAYS your best friend. Googling code issues was the way I was able to quickly learn advanced WordPress development.

Advanced Steps

After you’ve learned the basics, it’s time to choose where you want to go. Do you want to stay in front-end development and continue learning advanced HTML/CSS? You can always add in PHP and/or jQuery and be able to do almost anything a client would need.

What if you want to get into mobile apps? I can tell you from experience learning a software language like Objective-C is one of the hardest things to do. The syntax isn’t as easy as HTML and they aren’t really self-explanatory either.

Here are some ways I’ve found that make the learning process easier:

• Get a book - There are two kinds of coding books: books that teach the basics of the code, and books without much code, but that teach theory. I love getting HTML/CSS books that focus on semantics, usability and ways to clean up and optimize your code. However, if you choose to branch into a more advanced language, I’d recommend with starting with a regular coding book and getting a theory book after you’ve started with the basics.
• Learn theory & syntax – You don’t just need to know where to put a piece of code, you need to know WHY you put that piece of code there. For example, why use a float instead of a position?  Margins instead of padding? Every code language has a rhyme and reason to it, and you’ll never fully understand the language until you understand it’s structure and theory.
• Do something – Example books are great, but just following the examples doesn’t get you anywhere far. After you’ve followed and example and learned how to do something, stop and make your own app or example. See if you can redo it without looking back at the book for help. The most I’ve ever learned have always come from personal projects.
• Ask for help – There’s nothing wrong with asking the community for help as long as they can see you’re actually trying to learn it and not just asking for free work. Sites like Twitter, Stack Overflow and *shameless plug* Codesnipp.it are filled with happy and helpful devs ready to answer any sort of bizarre coding questions you can think of.
• Tutorials – I recently started following MobileTuts+ because they had some awesome tutorials and theory articles for iPhone development. And this is really saying something because I HATE tutorials.

The Best Tip Ever For Learning Anything In Life…

…is just to start doing it. You can go through 100 development books, several classes and tutorials and never learn anything. The best way (and I’m guilty of not doing this yet for Obj-C) to learn it is to go out and start building stuff with it. Perfectionism comes with time and practice!

Advice?

What’s your advice for learning advanced development languages? Are you having any problems learning?

If you follow me on Twitter or on Facebook, you’ve probably heard me talk about the mobile site I’ve been developing for Amazon Audible.

The mobile site consists of over 50 mockups that needed to be developed in HTML/CSS and made to work for the iPhone, Android and Blackberry. While coding simple HTML/CSS mockups sounded pretty easy, I found that there were several hurdles and differences from doing mobile HTML and normal HTML.

Doing a mobile site from scratch was a big learning experience, so I’d thought I’d share some of the things I learned, that differed greatly for mobile dev.

Think Small

Doing mobile development means you have to think small and in terms of percentages, not pixels. You can’t have a 320px layout for the iPhone, because if you rotate the phone into landscape mode, you’ll have a skinny site running down the middle. You have to make sure the layout stays consist, while expanding for both portrait and landscape modes on the phone.

CSS3 Wonders

One of the biggest changes that were difficult for me to get over, and one of the best, was the fact that I could use CSS3 freely. I no longer had to worry about Internet Explorer, and al of the prominent mobile devices support it.

When trying to do some tricky styling without adding additional markup, I caught myself remembering that I could actually do it with nth-of-type and not having to worry about it breaking! So feel free to break out your CSS3 and even some of your HTML5 skills.

Special Meta Tags

There are a lot of little quirks in some mobile devices, but since I have an iPhone I’ll mention the ones I found in that device. The iPhone has this neat trick, where it links phone numbers in the browser and allows you to click on them and call them instantly.

This is awesome, except for the fact when it tries to do it on non-phone numbers. It seems to have difficulty sometimes determining what is and isn’t a number, especially when it comes to things like part/order numbers.

The awesome thing about Apple, however, is the fact they came up with a ton of meta tags that allow you to manipulate the way the iPhone device reads the website. I think these tags may also work on the Android, but don’t quote me on that.

To disallow the linking of phone numbers of your site, simple add this in between your <head> tags:

<meta name="format-detection" content="telephone=no">

I also ran across a problem where the iPhone likes to blow up the size of text in landscape mode, which was obviously a no-no and broke our layout. This was fixed simply by adding this style to the body property:

body { -webkit-text-size-adjust: none; }

The IE of Mobile

Of course, there’s always something that has to make a developer’s life difficult, and in this case it’s Blackberry. While it’s not as bad as Internet Explorer, it still became a thorn in my side.

Apparently, some models of Blackberries don’t support CSS3 properties, like opacity. I haven’t had any problems with advanced selectors though, so I’m not sure what is and isn’t supported.

The Blackberry also seemed to interpret spacing and paddings differently from the Android and the iPhone. For the most part, besides a few text differences, the Android and iPhone were quite similar in rendering the site.

Browser-Testing

Browser, or device, testing for mobile is a bit more difficult to do than normal web browser testing. While you can download pretty much al of the web browsers if you’re on a Windows machine (or use a simulator on a Mac), I’m fairly sure most devs don’t have an iPhone, Android AND a Blackberry.

For beginning testing, it was enough to resize my Firefox window as small as possible, but most of the testing I did on my iPhone, especially because the iPhone renders inputs and some backgrounds and paddings quite differently than Firefox.

For Android and Blackberry testing, I had to rely on the help of several of my Twitter friends (thanks guys!). A lot of the simulators you can download, especially the iPhone ones, never seem to actually renders the site like the actual device would. The client also had access to all three devices, so there were a big help in finding bugs.

Teaching the Client

The problem with percentage based designs, is that it’s impossible to have it “pixel-perfect” with the mockups, because you’re not using pixels. This was something I discovered early on, and something I had to teach the client about as well, especially because they had handed me size guides with the exact pixels everything was spaced out to.

This is a bit difficult to explain to a client who wants the mockups to look exactly the same in portrait and landscape mode, but with a little persistence and documentation, it wasn’t impossible for them to become relaxed in their layout expectations. You just have to be a bit more fluid when it comes to the mobile world.

Progress

I haven’t completed all the mockups yet, but you can check out the progress on the mobile site I’m working on for Audible for the next week or so before it’s taken down to become live.

Your Thoughts

What are some of the differences and difficulties you’ve experienced while coding for mobile sites?