Adobe has done the unthinkable, it’s actually bought two companies worth giving a crap about. Nitobi, makers of PhoneGap, and TypeKit, pioneers of the CSS3 web-font game, have been acquired by Adobe.

Adobe should be thrilled.

It’s now got two sets of highly skilled developers with great ideas and good products to work with. TypeKit is an obvious acquisition as it’ll be part of Adobe’s Creative Cloud offering that gives them the ability to use (and sample) a huge range of fonts across their apps.

Adobe have also promised that PhoneGap will remain open source, being donated to the Apache Software Foundation. This feels strange, as then Adobe just gets the developers at Nitobi themselves (who are obviously very good). This begs the question: why did Adobe bother with it?

Well, Adobe is a tools company – they make programs that we make other cool things with. Nitobi was also a tools company, making PhoneGap, that lots of people made cool things with. Alongside the PhoneGap framework, there were two smaller projects, PhoneGap Build and Cordova.

PhoneGap Build takes the pain out of making PhoneGap apps for multiple platforms. If you’ve ever tried to do a build for iOS, Android and Blackberry, you know it’s a world of pain and about 10GB of tools and frameworks. PhoneGap Build takes this all away from you, and is a service that Adobe can integrate into their Cloud offering.

Cordova is the stand-alone desktop equivalent of PhoneGap Build. It’s creator, Brian LeRoux, recently said:

All the cli tooling prototyped in Cordova now first class in phonegap/[ios|android]. Time to update Cordova.

I take this to mean that Cordova is back in focus, and Adobe will be actively looking to integrate it into DreamWeaver, in the same way it integrated jQuery Mobile.

We should be wary

Adobe’s track record for mergers is not great. The Macromedia merger led to a focus on Flash and Photoshop, whereas other products like DreamWeaver and Fireworks were not given the time that they deserved. Lots of people lost their jobs in that merger too and I’d hate to see that happen to the guys at Nitobi or TypeKit.

We have to watch out for rising prices and being forced to buy products that we don’t need. I can see it already: with PhoneGap integrating with DreamWeaver, the easiest way to build a PhoneGap app will be with that product or Build. Yesterday, those in the PhoneGap Build program were sent a pricing structure:

PhoneGap Pricing Announcement

I can see these prices going up, and up (and they’re not that cheap to begin with). One build a day with the free package probably isn’t enough. I hope the same doesn’t occur with TypeKit, or people will just move to one of the other services that exist (Fonts.com for example).

The other danger is that somewhere down the line, these products that many have come to rely upon will simply cease to exist. Merged so deep into Adobe’s pipeline, the one thing that made them great, their independence, is stripped from them and the revolutions that they make simply slow down and stop. With the core of PhoneGap, we’ve been promised that they’ll actually have more time for it and I hope this continues for as long as possible. What I’d hate to see is the core being neglected in favor of tools for products that I don’t want to buy.

Fingers crossed that Adobe will really make something good this time, and that their commitment to the web and web standards continues, but I won’t be holding my breath.

If you liked this, you may also like:

1. Executive Summary: Flash vs HTML5
2. Easy iPhone Applications
3. 5 Rules for a great workspace

After a summer break, London Web Standards was back with an evening of WebGL with Ilmari Heikkenen from Google and a short demo from Carlos Ulloa of HelloEnjoy. Sketchnotes are below

Carlos Ulloa of Brighton-based HelloEnjoy showed off two demos that he made using Three.js and WebGL. The first was HelloRacer, an interactive look at the 2010 Ferrari F1 car that you can even drive and do handbrake turns in. The second demo got it premiere at LWS, an interactive music video for Ellie Goulding’s “Lights”. Honestly, it was extremely cool, on a Ro.me “3 dreams of black” scale. It’ll appear at the linked URL in the next week or so. There’s a great Q&A session on the London Web Standards blog of the event for more detail on how they did it.

Ilmari Heikkenen showed the gathered crowd how to make a basic WebGL app using Three.js in about 50 lines. He showed off all of the components that you need: a renderer, scene, camera, mesh and lights (and shadows). He went into more depth about vertex shaders and fragment shaders, the GPU effects that make everything look a lot more real.

Ilmari gave examples of a few uses, including games, 3D bar charts and scatter graphs. He then started animating all of these, including a 10,000 point scattergraph that moved in real-time. Finally, he demonstrated a loader for Collada meshes (supported by Maya) and brought in a monster that with a few lines of code started walking around the screen.

Overall, it was a great introduction to the subject, one worth a lot more of your time.

Ilmari’s slides can be found on his blog.

If you liked this, you may also like:

1. Future of Web Design Sketchnotes – Day 1
2. Future of Web Design Sketchnotes – Day 2
3. So, you want an app?

If you’ve developed for Microsoft’s SharePoint before (I’m talking about 2007 here, but this applies to WSS2 and 2010 as well) , then you’ll know that you can reach the limits of it’s functionality very quickly. This is a big problem if you’re making a zero-code solution, i.e. you have no access to Visual Studio and can’t create web parts. This is more common than you’d think, especially in large organisations that use SharePoint extensively. For this, the only choice is to use SharePoint Designer 2007 (SPD), but it’s not pleasant because, frankly, SPD sucks. I’ve not found a program that crashes as much as SPD, or that performs so poorly when presented with the most basic tasks. If you make a page that is too complex, has too many web parts, large data sources or lots of conditionals, connections and filters, it can take anywhere up to 20 minutes to perform a single action.

Very quickly, you have to start looking at alternatives to complex data views. These days, the go-to technology is JavaScript, which is very powerful and can allow developers to access almost every SharePoint function through web services. However, this functionality comes at the cost of accessibility. So, the first piece of advice: if you can avoid using JavaScript, do so because otherwise the site won’t be accessible. See these links for why accessibility is a good thing.

Unfortunately, SharePoint is so limited that often a JavaScript is the only way to add functionality in or to correct formatting. In this case, use of simple SPD functions and <noscript> tags can keep your content accessible, allowing you to progressively enhance the user’s experience on top.

The final hurdle to cross before you can create great JavaScript-based interfaces in SharePoint is IE.

Internet Explorer, especially IE6, has appalling developer tools for JavaScript debugging. There’s no console, inspector, breakpoint facility, no nothing. It’s almost impossible to debug your problems because they all manifest themselves as runtime errors on some arbitrary line on the page.

The best way that you can debug JavaScript in IE, is with Google Chrome. It doesn’t sound right, but I promise it’s the easiest way to make your code work. Both Chrome’s Web Inspector and Firefox’s Firebug work very well with SharePoint, though my personal preference is for Chrome as it works better with Windows’ NTLM authentication system (it doesn’t ask you for your login details, just takes them from Windows). They allow you to check and validate your code so that it works well and runs as expected. You should be able to achieve this in half the time that you would if you were just developing for IE, using alerts to work out what’s going wrong.

There’s another benefit for working this way around: your code will work on standards-compliant browsers, and any that come along in the future. This is always a good thing as you don’t know when the organisation will roll out IE8/9 to its users, nor can you always guarantee that a user will be using a IE. It’s important that sites are ready for these changes and best-practice development is maintained.

In summary, if you have to use JavaScript, ensure the page content will work without it. If you are doing any major development work, do it in Chrome and reap the benefits of its debugger, then make it work in IE.

If you liked this, you may also like:

1. Improving Javascript XML Node Finding Performance by 2000%
2. Problems loading local fonts with font-family
3. Chrome or Opera

Web applications are the next big thing in the web. Being able to take web sites and make them run alongside native apps, having them work offline and perform just as well as their native counterparts is the next step along the road. As usual, with all new technology, there are some limitations.

There are three pieces of technology that are combined to make a web app: app caching, local storage and a web database technology.
App caching tells browsers what files to store offline and retrieve from disk. These are permanently stored until new instructions are received, unlike traditional caching which works until the cache is full, then starts removing files.

Limitation 1
In iOS 4.3, app caching for offline web apps is broken and does not work.

Local storage is for key/value pairs of information. It’s for simple things like settings and values that need to be retrieved quickly. It’s been called “cookies on crack” before, but it’s really just a very fast dictionary for simple data.

Limitation 2
Depending on your browser, localStorage will keep 5-10MB of data, the equivalent of 200,000-500,000 characters. If all you want to do is store small serialised JSON objects that aren’t related, use this.

Web databases are client-side data storage for larger amounts of more complex data. Whilst you can make web apps with just app caching and local storage, it’s not going to be very interactive, or the data may be unstructured, or there will be lots of Ajax calls to fetch data. Web databases are where this technology gets a bit dodgy.

Originally, there was Google Gears, a plug-in which brought a SQLite database to help web apps run offline. This was then standardised into the WebSQL module and developed as a SQL database available through JavaScript. Google, Apple and Opera all implemented it and it can be found in iOS and Android devices today.

Limitation 3
Chrome has a hard 5MB database size limit – you will need to use a chrome web app to remove this limit.
Limitation 4
Chrome doesn’t support OUTER JOIN or RIGHT JOIN statements.
Limitation 5
Debugging is very difficult with large amounts of data as the web inspector isn’t efficient at displaying a thousand rows (and will crash with around 20,000 rows, around 2MB of data).
Limitation 6
Version numbers are not taken into account. Don’t bother with them.
Limitation 7
All calls are asynchronous – if you rely on results at a certain time, be prepared to write a lot of callback functions. Your code can get messy very quickly.
Limitation 8
Performance is sluggish if you don’t batch up statements into transactions.

Even better still, WebSQL is no longer in development, so these problems will remain. Microsoft and Mozilla said they didn’t like it and wanted to used a different technology: IndexedDB.

IndexedDB is on it’s way, but not mature enough yet to be used, nor is it implemented in any of the mobile browsers.

Advice
For offline apps, you’re better sticking with WebSQL until IndexedDB matures.

Hopefully, some kind developer will come along and write a technology-agnostic wrapper, maybe that person will be you, the reader of this article. If you’re thinking about it, let me know

If you liked this, you may also like:

1. Why iPhone Web Apps are Still Worthwhile
2. 8 HTML5 Features You Haven’t Seen Before at #lwsdeep
3. Tips and Problems when Enhancing SharePoint with JavaScript

Over the last few days I attended the Future of Web Design conference in central London. It was a great two days meeting some of my peers and heroes of web design. Here’s my notes from day 1 including talks from Aaron Walters, Mike Kus, Rachel Andrew, Robin Christopherson, Daniel Rhatihgan, Sarah Parmenter, Dan Rubin, Matt Gifford and Aral Balkan.

Day 2 sketchnotes can be found behind this link.

If you liked this, you may also like:

1. Future of Web Design Sketchnotes – Day 2
2. Sketchnotes from #LWS3D – A 50-line WebGL app
3. The Progressive Web with Andy Hume (LWS Future)

This month, Marcus Alexander of EMC Consulting and Arran Ross-Paterson (of this parish) talk about HTML in the real world, dealing with clients, and what a quality project actually looks like.

LWSWorld - Real world HTML - Marcus Alexander

Everything is designed that way for a reason
Semantic HTML may be brilliant, but all those extra bits are in there for a reason. Until you understand them, don’t mess with them

The best solution is the one that meets the requirements
Clients don’t really care about the technology, just about getting things done on time and on budget. If a solution meets all the requirements, it doesn’t matter how hacky it is, it’s the right solution.

Ask the right questions up front
The client may not have thought of everything, so go through your standard checklist of questions and get everything agreed before you start.

Bugs happen, deal with it
100 bugs in a project is normal, most of them will be problems with other people’s code. Deal with them and try not to let the client get carried away. Products will ship with bugs, just deal with them.

Developers will build a rocket ship to get to Ikea
And then they’ll only leave room in the rocket for a hot dog and some light bulbs. Internal coding standards aren’t very useful, try code reviews and examples of structure instead.

Deployment scripts are your friend
They do all the grunt work for a release for you. Make use of ANT or MSBuild to speed things up.

Finally, thanks to Marcus for a great talk. Update: his slides are on slideshare: http://slidesha.re/980xv4 See my notes on this meetup’s other talk: Arran Ross-Paterson on Why validate

If you liked this, you may also like:

1. Why Validate? – Arran Ross-Paterson #LWSWorld
2. HTML 5 Forms – a spammers paradise
3. Real-time Analytics

This month, Marcus Alexander of EMC Consulting and Arran Ross-Paterson (of this parish) talk about HTML in the real world, dealing with clients, and what a quality project actually looks like.

These are my notes on Arran’s talk:

LWSWorld - Why Validate - Arran Ross-Paterson

Greeted by boos from the crowd, Arran’s controversial talk focused on why we shouldn’t worry that our web sites don’t validate in the W3C checker.

Validation
Browsers don’t care, nor does Google. Unless it’s a requirement, just use it as a sanity checker. Your code doesn’t always have to validate to be valid.

Alt tags
Alt tags never fully describe a picture. There’s no point in having an alt tag on an image if it’s not completely descriptive. If the image is just to attract attention, then don’t worry. If it’s an image map, you will need to add some more description.

Calendars
Calendars look like tables, but they could be a list, and surely it’s ordered, but if you’re doing an event calendar, a definition list is the most semantic markup, except that <dl>s are really hard to style and missing tags can cause problems. Having <dd> inside a <dt> isn’t correct according to the validator, but feels more correct semantically.

Don’t abandon standards
Standards are very useful, so don’t abandon them. They’re great for learning and teaching people, to bring them up to a certain level, but as long as it works, don’t sweat it.

Thanks again to Arran for his talk. See my notes tonight’s other talk: Marcus Alexander’s on real world HTML

If you liked this, you may also like:

1. Real World HTML with Marcus Alexander – #LWSWorld
2. The Progressive Web with Andy Hume (LWS Future)
3. UX Questions with Andy Budd

This month at london web standards, Opera’s Chris Mills (@chrisdavidmills) and Anna Debenham (@anna_debenham) came down to talk to us about education and the web. Anna has recently been through the UK education system and had her tales from the trenches of what it’s really like to be educated in the web at school.

Sketchnotes of

Curriculum
ICT education on the web and making web sites is awful. Since 2003, ICT has been mandatory at key stage 3 and 4 (SATS and GSCEs or ages 14 and 16 (ish)). Over the past few years, the curriculum has been so basic that children often know more than their teachers. This isn’t the teacher’s fault.

Anna showed us some of the resources teachers are given and one of the bits of coursework. The website was for the band “purple spiders” and consisted of some images, links and a purple background colour. Seriously, it was as basic as that. There were form pages with no submit button. Music download pages that said if you downloaded music you were a criminal.

Software
Teachers have a certain amount of recommended software, and principally it’s MS Office. If it’s not on the list they don’t get funding for it. Almost zero open source software is to be found. Every course told you to use tables for layout, because that’s what the software can do well. Ofsted, the teaching governing body, recognise that ICT is misused.

EdExcel, the examining body, seem to be rising above this. Their 2011 curriculum has encouraging statements like “knowledge of accessibility” and “creative commons”.

Age perception
Anna talked about the perception of age in the web world. There  are many success stories, including Matt Mullenweg creating WordPress before his 18th birthday. However, there is a general bias against young people in that experience counts in web design.

Anna also taught us that Flash is terrorism. She put a flash-based interactive room map of her school on their web site which they wouldn’t allow because “it would aid terrorism”. You heard it here first.

How to help
So, what can we do? Courses need to be made more interesting and relevant. Whilst “common software” like Office won’t go away any time soon, the teachers need better resources, and importantly, better tools. Adobe can help here, and so can Microsoft, making their most common tools more web-standards oriented.

If you liked this, you may also like:

1. A Web Sized Education Problem at #LWSEdu
2. Steel-Software.com reborn
3. Real-time Analytics

This month at london web standards, Opera’s Chris Mills (@chrisdavidmills) and Anna Debenham (@anna_debenham) came down to talk to us about education and the web. Chris talked about the state of adult and professional education.

Sketchnotes for

Chris talked about certificates and courses in web design. Most computing courses are little or no better than the GCSE courses, teaching the very basics of HTML markup, and then all the way to E-commerce without teaching the middle. Many of these courses were written 10-15 years ago and still have the hangovers of the pre-CSS era.

Things that must be eradicated from web education:

1. Tables as layout, spacer.gif, inline javascript
2. Resources on HTML3 and Netscape
3. Courses that try to fly before crawling
4. Dumb sysadmin policies (lock into IE6)

There are solutions:

• The Web Standards Curriculum (Opera)
• WaSP InterACT
• WaSP Education Task Force
• Interacting with web standards (book)
• Mozilla portfolio project – students projects are marked by professionals and portfolios created.
• Open Web Education Alliance (OWEA)

We need to teach the tools to learn, rather than teaching someone an evolving field. Web design is not like computer science, where underlying principles can be easily taught, it’s an art form.

So, web community, reach out, create resources for learning and teach people how to teach themselves.

The slides are up at slide share

If you liked this, you may also like:

1. Tales from the Trenches at #LWSEdu
2. The Progressive Web with Andy Hume (LWS Future)
3. Javascript Fun at London Web Standards #lwsfun

Monday night (16th August 2010) was London Web Standards‘ ‘Web Futures’ event with presentations from Clear Left‘s Andy Hume (@andyhume) and Richard Rutter (@clagnut).

This is part covering Andy’s talk which was on “The Progressive Web”. First up, my sketchnotes.

Sketch Notes of The Progressive Web, apologies to Andy Hume

The basic message of Andy’s talk is that the landscape of the web these days (note my awesome rolling hills) has changed and people should be more open to these new techniques. By designing and coding sites for today and tomorrow, you are not only reducing the amount of work you have to do now, but you’re decreasing the number of bugs, not having to re-do gradients for high-resolution displays, and you’re also making your web site faster, which is directly linked to revenue. There’s no reason not to add these things in now unless you’re designing entirely for IE6.

Andy talked extensively about @media queries, how these should be used instead of browser sniffing (read: should do feature detection) and how they can make simple websites work better across more web-enabled devices. He demonstrated the dConstruct website as a good example of this.

Andy put up two great slides, one on when you can use HTML5/CSS3 standards today, and where you should use intermediaries like jQuery. The other slide is poorly reproduced in my sketchnotes (middle-right), showing the cycle between standards, new hacks, old hacks and back to standards. This indicates a whole new era of innovation in the web now that we have these new standards.

So, a great talk by Andy. Read part two, on the future of web typography by Richard Rutter.

If you liked this, you may also like:

1. The Future of Web Typography with Richard Rutter (LWS Future)
2. UX Questions with Andy Budd
3. Future of Web Design Sketchnotes – Day 1