A Spacious place

I had a request the other day to find login details for the administrator of an old client website that we built for Dundee University in the earlier years of wideopenspace, the web design company I used to run. I hadn’t realised that the old client site was still up and running all this time after having been launched in 2006!

It was an amazing nostalgic blast-from-the-past to log in to the site’s control panel and see our custom-built content management system again! I’d kind of forgotten about the 100’s (actually, more like 1000’s!) of hours worth of time and effort that my business partner Andy and I put in to developing it and implementing it on client projects.

The CMS was called ‘Spacious’* and actually came in two versions, the full version with a multi-level navigation system and various custom modules and a ‘Spacious Lite’ version which was made for really small sites with single level navigation and also had access to certain modules.

Last logged in on 14/07/11, it had definitely been a while!

When we started development of our CMS around 2004 we hadn’t really used any third-party CMS platforms (WordPress V1 actually came out in 2004 but it wasn’t really on our radar). Instead we wanted to make something that suited our own specific purposes and client needs. So we didn’t really look at how any other CMS’s were doing things but in a kind of intentionally-naive way built it to work how we wanted it to work for the sites we were building for clients.

We used Spacious for a quite a lot of sites and we actually tried to secure funding to enable us to develop it into a fully fledged CMS product to sell to other companies, but sadly we never succeeded in getting funded. Eventually we stopped developing Spacious and as a company we increasingly moved our focus to WordPress as a platform around about 2009 (probably WordPress 2.7 I think?).

Client budgets were getting tighter and awareness of open source systems like WordPress was increasing. As such it was getting harder to sell clients a licence for a commercial CMS so financially the time spent building and maintaining our own one made less and less sense.

From a development perspective I found that WordPress had a lot of technical similarities to how we’d chosen to structure our CMS. Spacious had similar concepts of posts and pages, a plugin system offering various functions like Events, Email contact forms, Staff directories (‘modules’ in Spacious’ terminology), comments and even a form of multisite that could run more than one site from a single installation. (Spacious had some really cool features built into it that I’m pretty proud of in retrospect!)

From a client-facing perspective I liked the simplicity of WordPress, it was cognitively easy to use – especially compared to the complexities of something like Joomla at the time (I remember seeing all the steps that an incoming new client had to go through to edit their existing site in Joomla and it was extremely complex and confusing!).

As WordPress became our main focus the list of live client sites running Spacious grew shorter. So it’s very cool to see not just one but actually two sites that are still live and running on Spacious after all this time!


* Originally we wanted to call it ‘Fabric’ and trademark it but we weren’t successful – that’s a whole other story!

“Vague but exciting.”

In 1989 I was just about to finish High School and start my post-secondary school education path. At that time I really didn’t have much of an idea about what I wanted to do, other than going skateboarding I was only really interested in art and design, so off to college to study art and design I went.

Elsewhere in the world in 1989 Tim Berners-Lee submitted a document called “Information Management: A Proposal”* which proposed a large hypertext database that enabled the sharing of information between multiple computers, and from this the World Wide Web was born.

A few years later in 1993 I got my first taste of the internet, cheekily using a friend’s login details at University! Initially I used Gopher to browse through archives of NASA space photos, but soon after came the release of NCSA Mosaic, the first popular web browser, and I started accessing this “new thing” called the World Wide Web.

In 1994 I started my first year at Art College which gave me legitimate access to the internet (without having to use a friend’s login details!). “View source” became my teacher, and I spent hours telnet-ing into the main web server and learning how to write HTML. I didn’t realise it at the time but these were skills that were going to lead me in a career trajectory for the next 2 or 3 decades up to the present time.

Anyway, all this is to say “Happy 30th Birthday” to the World Wide Web and thanks to Tim Berners-Lee for inventing it!

This NeXT workstation was used by Tim Berners-Lee to run the first ever web-server.

If you want to see what it was like to use the first web browser then go and check out the “CERN 2019 WorldWideWeb Rebuild” project which rebuilt the original browser running inside a modern browser (inception!):

https://worldwideweb.cern.ch

* The proposal elicited the “Vague but exciting” response from Tim’s boss, which sounds a bit how I saw my future in 1989 ;)

WatchOS 5 adds support for web content rendering

Apple recently announced updates to the core software on all of their hardware platforms with various interesting new features.

One feature that jumped out when looking through it all was support for displaying web content in watchOS 5, it’s important to clarify that they haven’t added a standalone Safari app to watchOS but instead it enables any links sent via Mail or Messages to be accessed and then displayed right on the watch.

To get a quick overview it is worth taking a few minutes to watch the “Designing Web Content for watchOS” video on the WWDC2018 videos site as it gives a good overview.

Here’s a few thoughts and info about key aspects that I picked up from watching the video:

User navigation / interaction

  • You can scroll using the Apple Watch’s digital crown or via pan gestures
  • Double-tap to zoom in / out on the page content
  • Back/Forward navigation is controlled either via an overlay UI brought up via a  firm press on the screen or by swiping back and forward from the edges of the screen.

Web browser feature support

Content is optimised for display on the Apple Watch so certain features are not supported in watchOS 5:

  • Video playback
  • Service workers
  • Web fonts

If the web content being accessed is responsive then it treats the content as being 320px wide, the same width as if on an iPhone SE (iPhone 5 or older width). So text may be smaller but at least it will basically render the smallest breakpoint content, so it doesn’t require any new even smaller breakpoint to be catered for.

This is done by overriding the “initial-scale” value and provides a viewport with the dimensions 320px by 357px and reports a media query size of 320px. So existing responsive content will render on the Apple Watch without requiring any changes – at least from a layout perspective, worth noting the lack of support for Web fonts as this will likely have some rendering impact as it falls back to alternative fonts in the font stack do display.

Optimising content for Apple Watch

Even though responsive content will be rendered quite well by default it is possible to optimise content for display on Apple Watch.

The above image shows the standard responsive content being displayed on the Apple Watch, basically just the same as it would be on an iPhone SE (minus any web fonts of course!).

Responsive Layout on Apple Watch

Using a media query it is possible to modify this layout to display as a single column. There is an example given in the video which obviously won’t apply for all uses, but basically it uses “min-width: 320px” as the baseline for showing the content as two columns, so any content below that would render as a single column. Again, how this works specifically for your layouts will vary, but there will be some methods to use for frameworks like Foundation or Bootstrap etc.

“Disabled-adaptations” meta tag

The important addition to using a media query though is a new meta tag which disables the default adaptations that the Apple Watch makes when rendering content by default:

<meta name=”disabled-adaptations” content=”watch”>

With this meta tag in place the device width will be treated as the real width of Apple Watch’s screen. This again has similarities to how content was handled when the iPhone originally came out, existing content is displayed as best as possible but there are ways to optimise for the device if you want to.

Form controls on watchOS

Making use of HTML5 form control types is really important on watchOS, setting the type attribute to “email”, “tel” etc will bring up a specific, full screen UI to allow interaction.

Additionally making use of labels, placeholder or aria-label attributes enhance the context given when interacting with these controls. Hopefully you’re using these already but here’s another reason to do so.

Safari Reader on watchOS

This is a feature found on iOS and macOS which basically formats pages to show a more readable version of web page content. It’s a little unclear from the video but it sounds like pages that are “text heavy” will get displayed using Reader, although I’m not 100% sure how that would be determined exactly if so. Perhaps this is a way to handle big pages that might have a lot of adverts on it? Reader view is an option that users can choose by firmly pressing on any page to bring up the navigation overlay, so even if content is displayed normally a more readable version can be accessed.

Semantic markup in Reader view on watchOS

Reader view makes good use of semantic markup, using the “article” tag helps the display of content, and attributes like “item-prop” and other semantic tags like “strong”, “em”, “blockquote” etc enhances the display of content in Reader on watchOS.

Open Graph meta tags

Using Open Graph meta tags is something that makes sharing content around the web such as into Facebook, Twitter etc look better by providing specific preview content such as images, titles etc. watchOS makes use of these Open Graph meta tags to make the previews for any shared links look as good as possible.


That’s a quick overview of some aspects of watchOS 5’s support for web content, there’s definitely a few things to consider in there but if you’re building pages using responsive layouts and using semantic HTML then things should work fairly well without having to do anything.

The biggest issue I see initially is the lack of support for web fonts, that seems like it could cause some display issues due to the fallback to alternative fonts in the stack or if web fonts have been used for icons etc.

I’m also interested to know what the impact on battery life on the watch is like when loading and rendering multi-megabyte web pages which are not uncommon these days, I think Reader view is going to be an essential feature for viewing web content on Apple Watch.

Rise of the Machines

As we move further into a post-Flash(1) web there’s a lot of excitement and hype about HTML5 and CSS3. These new technologies combined with the power of JavaScript frameworks like jQuery offer the potential to create much more dynamic, animated, interactive user experiences on the web.

Many tools are now being developed to make the creation of these experiences much easier (Edge, Sencha, Hype, MotionComposer, Animatable(2) etc). However, there’s a potential danger lurking under the surface with these apps and the many demos and samples showing off these new shiny features: Machine Generated Code.

Made in the image of Flash

Any serious web developer would not consider the HTML code rendered by tools like Apple’s iWeb to be clean or optimal but rather to be bloated and messy. With the rise of ‘HTML5’ and the previously mentioned apps it seems that some normally standards-aware developers are being swept along with the buzz, happy that you can now do all these cool animations that are ‘standards based’. But if you take a look underneath the surface and examine the code being output then there are causes for concern — a high or total dependency on JavaScript to generate HTML content, bloated ‘divvy’ code and no consideration for fallback content or graceful degradation.

The content created might be made using web standards like HTML5, CSS3 and SVG but in reality it fails in exactly the same way that Flash does — poor / non-existant semantic structure and a lack of accessibility(3).

Web apps

Another form of Machine Generated Code that is manifesting on the web is within many popular web apps. Take a look at the code under the hood of Google+ and you’ll see something like this:

Is that code any better than the code that is generated by iWeb? It’s possibly worse. How can a company like Google who has incredibly talented developers end up with code like that? Well, in Google’s case it was written using a templating system that uses Closure, these templates are converted by java on the server into HTML(4). Nothing inherently wrong with that process but the end result is HTML that is machine-friendly but is not really intended to be easily readable by humans.

So it seems that with the ‘rise of the machines’ demonstrated by tools like Edge, Sencha and Hype along with development frameworks like those used by Google that there is a loss of focus on the best practices of clean code, graceful degradation, progressive enhancement, accessibility. Instead the focus is on easy generation of code and content, with Edge and Sencha giving a visual WYSIWYG-ish interface with which to create it, and Google’s Closure / Java dev process enabling code-savvy devs to write in a non-web native language and have this automatically generated or compiled into the final HTML and JavaScript.

(Of course a counter-argument is that clean semantic HTML code doesn’t apply to web apps as they are ‘more complex’ than ‘regular’ websites! That’s something for further discussion).

Change begins at home

So, is there a solution to this? Well, the first solution is to consider these issues yourself. If you’re evaluating tools like Edge, Sencha or evaluating development frameworks then pay close attention to the code they create. If it seems to be falling short then take the time to give feedback to the companies behind them. In the case of Adobe’s Edge tool which is currently an early preview release on Adobe Labs then there is an opportunity to give feedback on the app and influence it at an early stage of development. Don’t just whine about it on Twitter but take the time to give feedback and clearly explain what you think is wrong and how it can be improved.

Muse

Talking of people whining on Twitter, I wrote this article and had it all pretty much ready to publish when Adobe released another product on Adobe Labs, Muse. Although the main focus of this article is on the more interactive, dynamic flash-esque content creation applications that have been appearing I couldn’t really post this article without briefly mentioning Muse (I did mention iWeb and talk about Google+ after all, both of which obviously don’t fit that category of app).

Muse definitely renders Machine Generated Code as it’s sole aim is to enable visual designers to “Design and publish HTML websites without writing code”. I have to admit that the first thing I did when viewing the Muse website (which is itself built with Muse) was to view source, and sadly I was disappointed with what I saw there – lots of nested divs, generally bloated looking content, and despite purportedly being ‘HTML5’ there were no HTML5 structural tags to be seen.

Many WYSIWYG apps have come and gone and have never managed to produce good clean code without requiring the user to intervene and clean up code, this doesn’t mean it’s impossible to create such an app, but it’s definitely a big challenge. As with Adobe Edge I’d recommend taking time to give good, reasoned feedback about what you consider is wrong with the output it produces, don’t just complain about it on Twitter.

Christian Heilmann wrote an interesting article called “Getting rusty – we need new best practices for a different development world” which I think gives an interesting pragmatic perspective on the debate about Machine Generated Code and why we rightly consider clean, semantic code desirable as opposed to that produced by apps like iWeb, Edge, Hype, Muse etc. His final couple of paragraphs sum up the thoughts and feelings that inspired me to write this post:

“Using web standards means first and foremost one thing: delivering a clean, professional job. You don’t write clean markup for the browser, you don’t write it for the end users. You write it for the person who takes over the job from you. Much like you should use good grammar in a CV and not write it in crayon you can not expect to get the respect from people maintaining your code when you leave a mess that “works”.

And this is what we need to try to make new developers understand. It is about pride in delivering a clean job. Not about using the newest technology and chasing the shiny. For ourselves we have to understand that the only one who really cared about our beloved standards and separation of concerns is us – as we think maintainability and not quick deployment and continuous iteration of code. The web is not code – the web is a medium where we use a mix of technologies fit for the purpose on hand to deliver a great experience for the end users.”

Footnotes:

  • 1: By post-Flash I mean as the only way to do interactive animated content on the web.
  • 2: Animatable looks to be one of the most promising apps being developed as the team behind it have kept the whole concept of falling back to non-animated content as core to the way the app works, basing it on actual HTML content rather than just created through JavaScript.
  • 3: I acknowledge that it is possible with recent versions of the Flash player to make Flash content that is more accessible, but generally Flash’s integration with Screen readers like Jaws etc is not great, and you have to specifically apply settings to the Flash content to help it be accessible.
  • 4: This information about Google+ development and other interesting info from this thread.

My thoughts on Adobe Edge

Today Adobe published on their Adobe Labs website a public preview of a new application called Edge, which is described in their own words as:

"Adobe® Edge Preview is a new web motion and interaction design tool that allows designers to bring animated content to websites, using web standards like HTML5, JavaScript, and CSS3."

Having previously done a little comparison between the output contents and file size of their previously released Wallaby ‘Flash to HTML5’ conversion tool and that of Flash itself then I thought it would be good to do the same thing for Edge. However, the problem at the moment is – being only the first preview release – Edge has a fairly limited featureset with animation methods such as rotation, location (X / Y axis movement), opacity, scaling and skewing. Essentially some of the basic animation tools that you’d find in Flash. The problem with trying to do a comparison along the lines of the Wallaby test that I did is that I used a shape-tweened animation for that test, something which just isn’t possible at this time within the capabilities of Edge.

So, in lieu of being able to do a really exact comparison I have instead made a simple animation using one of the original SVG source graphics that I used for my Wallaby test. The main outcome of doing this test is just to see what the output of Edge is like – how many files does it create, how big is each file individually and in total. If you haven’t read the previous Wallaby post prior to this then in a nutshell the Flash output was far more efficient in both number of files and file size. Again it has to be said that a shape-tween animation is probably the most complex type of animation you could aim to do in this context, so I did set the bar fairly high there. But as tools like Edge and Wallaby are an attempt to try and bring Flash-esque timeline based animation creation to the world of HTML5/CSS/JS/SVG then it’s fair to expect that beyond some simple x/y movement and rotation that shape-tweening is something that people – especially those from a Flash background – will want to create.

‘Edge Case’ sample: Rotating an SVG in Adobe Edge

So, here’s the simple animation I created in Edge. I imported an SVG file which I had used for the Wallaby test and applied a simple 360 degree rotation to it, a lot simpler than the Wallaby test but I thought it was worthwhile bringing in an SVG file to see what Edge did with it.


View Edge’s Output in new Window
Download the Edge Assets as a Zip

Adobe Edge’s ouput HTML, CSS, JS etc

Here are all the files that Edge created for this example:

  • edge-case.html: 1kb
  • edge_includes/jquery-1.4.2.min.js: 72kb
  • edge_includes/jquery.easing.1.3.js: 8kb
  • edge_includes/edge.0.1.1.min.js: 32kb
  • edge_includes/edge.symbol.0.1.1.min.js: 29kb
  • edge-case_edge.js: 5kb
  • edge-case_edge.css: 1kb
  • images/noun_project_182.svg: 1kb

Total: 149kb

So, to get that basic rotation animation of an SVG file we get almost a 150kb payload in order to make that work. I haven’t bothered creating a Flash (or video) version of this animation as I think it’s fairly clear that it would be possible to get a smaller file size using Flash to create it. Edge and tools like it have obviously got their work cut out here, especially with the huge use of mobile devices then file sizes and number of separate files in a site (i.e. minimising server calls etc) is an important issue.

We’ve definitely got to cut Edge some slack though here, as small as Flash files can be it’s important to remember that the entire runtime for Flash is a plugin whereas as HTML / CSS / JS etc is supported by the browser’s native features, Also the JS files used by Edge are providing a kind of runtime in the form of some Javascript functions which gets added to every animation that you create with it. Presumably this could be alleviated by having this file be published only once and then referenced, or better yet by being hosted by Google’s CDN and referenced that way along with jQuery which Edge also includes with each animation.

Adobe Edge: Just a tool for Flash-ers or true HTML based creation?

It’s hard to say at this point how these tools will be used, a big area will surely be a replacement for Flash-based interactive / animated advertising, again file size is very important here as Flash banner ads often have a maxmimum payload for ad networks of about 40kb, so Edge is not competitive here.

I think my biggest concern about these tools is that they simply become a swap-in replacement for Flash and that people start to use them purely from a visual perspective and not considering the structure and semantic meaning which underlies all HTML pages. It is *HTML*5 after all, even though that term is often used as a buzzword to include JavaScript effects, technologies such as Canvas, SVG etc. It is extremely important to remember that semantic meaning is at the core of HTML. As such animations created with tools like Edge should keep that at heart and include a workflow that encourages this fact, not just enabling ways to make things move around the screen etc. So I’ll be interested to see how things progress with Edge.

Despite that concern it is still great to see tools like Edge and Sencha Animator being released, the uptake of complex JavaScript based interaction and animation is certainly hindered most by the lack of capable IDE’s to make the process quicker to do. Hand coding jQuery animation and interaction is fine but a good IDE would enable you to keep on top of the code being used but also make it much quicker and efficient to develop using these technologies.

Anyway, that’s my thoughts having played around with Edge, I’ll have to go catch up with some reading online and see what other people are saying, feel free to comment with your own thoughts!

Adobe Labs release Wallaby Flash to HTML5 converter

Adobe have released an interesting experimental tool called ‘Wallaby‘ over on Adobe Labs. It’s basically an app that tries to convert Flash FLA source files into ‘HTML5’ compatible animations. Note I’m using ‘HTML5’ in quotes as usage of the term here is more in the overall grouping of HTML5 and related technologies such as CSS3, JavaScript / jQuery, SVG etc. It’s worth reading over the Release Notes to get an idea of the current limitations, the biggest issues at the moment being WebKit browser support only and no conversion of actionscript or sound within FLAs.

I just happened to be playing around with Flash this morning messing around doing a little shape tweening with a couple of symbols I found over on The Noun Project website so I thought I’d use that FLA file and see how Wallaby coped with it.

Running Wallaby:

After starting Wallaby you get a very simple interface, a file select field that you use to select the FLA file and a large Status area that shows any errors and warnings encountered whilst converting your file. There are also Preferences that can be set which at the moment include automatically opening the converted file in your default browser and enabling logging.

After selecting my FLA file I clicked ‘Convert’ and after a few seconds it happily converted my file without any errors or warnings. I was interested to see what it would make of the shape tweened animation that I had made in Flash as this seemed like quite a challenge to convert.

Wallaby’s HTML output:

The conversion process results in quite a few files being exported as the animation is recreated using a combination of HTML, CSS and jQuery / JavaScript, here a screenshot of the files I got:

It turns out that to make an HTML version of our tweened FLA animation we need two JavaScript files, one CSS file, one HTML file and a folder containing 246 SVG frames. I think it’s fair to say that tweened animations are a bit of a challenge! Looking at the Release Notes it does state that it creates an SVG file for each frame of a shape tween. As a result the approximate sizes of the exported files look like this:

  • Energy-html.html: 75kb
  • Energy.css: 49kb
  • Energy.js: 2kb
  • jquery-1.4.2.js: 70kb
  • Energy_assets: 176kb

That’s a total of 372kb in order to recreate the tweened animation in HTML / CSS / JS / SVG.

Flash’s output:

So how does this compare with the files output by Flash? Well, not very well when you look at both the amount of files required and their file size:

  • Energy-flash.html: 2kb
  • Energy.swf: 4kb

A grand total of 6kb when it’s rendered as Flash swf output. That’s quite a difference in size, although admittedly Flash’s default HTML file doesn’t use any JavaScript such as SWFObject to embed the file which is generally common practice, so I would argue that the Flash output should really have the following additional SWFObject files added to it’s output:

  • swfobject.js: 10kb
  • expressInstall.swf: 1kb

Even with that it’s still only a total of 17kb, about 1/20th the total size of the files that Wallaby outputs.

Why not use video instead?

This particular animation is obviously a challenge for Wallaby to convert into anything closely competing in file size, so perhaps in this case it would be a better option to use a video clip to provide a non-Flash version of the animation? The same animation can be output as an H.264 video at the same frame rate and it comes in considerably smaller at 192kb:

  • Energy-video.html: 1kb
  • Energy.mov: 192kb

That’s about half the size of the Wallaby output. It’s also likely to playback much better on mobile devices such as iPhone / iPad / iPod touch as Adobe warn that the output of shape tweened animation can result in playback performance difficulties on iOS devices.

In the interest of being consistent I should of course add some additional JavaScript video embedding option such as JWPlayer as again this is common practice when it comes to adding video on web pages. Using JWPlayer would add the following additional files:

  • jwplayer.js: 104kb
  • player.swf: 96kb
  • yt.swf: 1kb

This adds 201kb to the total file size required so that brings it to about 393kb, almost the same as Wallaby’s HTML5 output. I’m sure there are possibly slimmer options compared to JWPlayer for embedding that could reduce that down a bit but I reference JWPlayer as I consider it to be one of the best cross-platform methods of embedding video on website.

Of course I haven’t mentioned anything about delivering video in alternative codecs such as Ogg Theora or WebM to serve browsers like Opera, Firefox and Chrome, this would further increase the files and sizes involved. However, given that Wallaby is trying to provide a way for animated content created in Flash to be output and made playable on devices such as the iPad and iPhone it could also be considered that providing any kind of Flash fallback for video is unnecessary, so we could ignore the JWPlayer / JS completely and just use the regular HTML5 <video> tag and a single H.264 video, so we’d be back to a considerably smaller size than Wallaby’s output in this instance.

In Closing…

Overall Wallaby looks to be a pretty handy tool for people that are struggling to find a way to get their content viewable on the millions of devices that don’t (and likely never will) run Flash. For animation that doesn’t involve shape tweening I think the resulting file sizes will be a lot more favourable and it will be a reasonably efficient way to create animated content using standards-based technology.

I would say that the primary target user for Wallaby, at least at first, is for people doing online advertising. This is an area that is seeing a lot of activity with tools like Sencha Touch appearing, there’s definitely opportunity for a ‘killer app’ that makes creating banner advertising using all of these new emerging web technologies in a way that people are used to doing in the Flash IDE. There’s a lot of challenges in there technically, as well as a lot of issues such as accessibility, graceful degradation etc, but I think a lot of companies are focusing on this challenge now, so it’s good to see that Adobe is thinking about various ways of providing tools for the job.

Sample Animation files:

I have included the HTML5 output as an iframe and also links to each animation in HTML5, SWF and H.264 formats. There is also a link to download all the assets of Wallaby’s output in a zip archive:

Wallaby’s HTML5 output:

View Wallaby’s HTML5 Output in new Window
Download the Wallaby HTML5 Assets as a Zip

SWF output:
View SWF Output in new Window

Video output:
View Video Output in new Window

Review: Adobe Dreamweaver CS5

Dreamweaver CS5 iconAdobe have just announced the new version of their Creative Suite software, CS5 adds a whole range of new features across the whole range of their applications.

As a web designer / developer it’s the updates to Dreamweaver CS5 that I’m most interested in. I’ve used Dreamweaver as my main development environment for years even though I’ve used it in a very code oriented way and haven’t relied much on the Design view mode in the application.;

Part of the reason I haven’t relied on the Design view aspect is that historically it was pretty poor at rendering more up to date HTML / CSS techniques. It was also unable to render the custom PHP code used in my own PHP applications or in any other PHP based CMS apps like WordPress, Drupal etc.;

Dreamweaver CS4 did bring some improvements with the addition of the WebKit framework as the rendering engine for Design view and Live view which solved a lot of the HTML / CSS rendering issues and added support for many of the CSS features that WebKit supports.

Improved PHP Code Hinting and Introspection, Live View

Dreamweaver CS5 takes those steps a good deal further and now adds greatly improved PHP Code Hinting which can discover your own PHP functions and classes as well as those in CMS frameworks WordPress, Drupal and Joomla. The major benefit of this for the Design view and Live view is that instead of a jumbled mess of un-renderable PHP and HTML code you get the actual site running right inside Dreamweaver.

Dreamweaver CS5 custom code introspection

When you combine this with the new Inspect mode you get the ability to inspect elements on your page and see the CSS properties used, it’s very similar to some of the features offered by the Firebug add-on for Firefox or Web Inspector inside Safari.

The combination of these features together make it a huge leap forward for code-based designer / developers like myself. If you’ve previously been put off by the rendering aspect of Dreamweaver before then it’s definitely worth checking out again.

What about HTML5, CSS3, Web font support?

There’s been a lot of noise about HTML5, CSS3 and Web Fonts (@font-face) in recent months, not least because of the prominent debate over Flash support on iPhone OS devices. A lot of people might expect Dreamweaver to add support for HTML5 and CSS3, however, at first glance you might be a bit disappointed.

David Powers over on the FoundationPHP blog wrote a great writeup of Dreamweaver CS5 in which he makes a valid point about the lack of prominent support for HTML5 and CSS3. The HTML5 and CSS3 standards are still evolving so it’s difficult for any IDE to add support for them without the risk of something changing or breaking, especially with the HTML5 standard.

Dreamweaver CS5 does however offer support for using the HTML5 doctype for your documents, also the WebKit framework used in Design view and Live view will also render many of the CSS3 features that the WebKit framework supports, so if you’re writing code by hand then you can still use and preview many of these CSS properties.

Dreamweaver's Live View rendering of Suburbia.org.uk

(The screenshot above shows https://qreate.co.uk viewed right inside Dreamweaver’s Live View, note the TypeKit fonts rendering happily inside Dreamweaver’s WebKit based Live view).

Web Fonts are still a hot potato in many ways so as yet there is no direct support for adding those within Dreamweaver, but again WebKit will render them so adding the @font-face code by hand will get you there.

CSS3 Code hintsThe good news for CSS3 and Font-face etc is that Dreamweaver can be extended very easily to add support for, even better news is that I have already written a couple of Extensions for Dreamweaver which can be downloaded for free from the Dreamweaver Exchange, you can also read a bit more about them on the Projects page of this site.

I’m hoping to write on to add support for HTML5 tags too, with these extensions you’ll get code hinting support for adding these into your code. Please try them out and give me feedback as to how they can be improved and I’ll see what I can do to make them better. David Powers has also written an extension for adding / converting RGBa colour values too which is another handy tool, you can download it and other useful DW extensions from his Extensions and Tools page.

Improved Subversion support

Subversion version control support was added with Dreamweaver CS4, however I wasn’t very keen on how it was implemented and it lacked many features so I’ve continued to use alternative standalone apps for managing version control on OSX. Subversion support has been improved in CS5 though so it looks to be a more viable option now, I will try and give it a fresh comparison to see how it compares to the standalone alternatives now. One major difference in CS5’s support I believe is that Subversion can be upgraded without Dreamweaver itself having to be updated so this will help keep it more up to date.

BrowserLab integration

Adobe BrowserLab logoI’ve written about BrowserLab before, BrowserLab is a great way to test web pages in different browsers and Adobe has continued to improve it by adding more target browsers to the list as well as the ability to save local copies of the rendered previews as jpeg images.

The integration of BrowserLab in CS5 along with all of the improved Live view rendering improvements makes for a great development environment. BrowserLab has been a free service so far as part of Adobe’s Labs beta program, it will however ultimately be a paid service but purchasers of CS5 software will get included access for a year. Standalone pricing has yet to be announced.

Recommended upgrade

All in all Dreamweaver CS5 is a great step forward, it’s definitely got some genuinely useful improvements to offer my own code-centric workflow especially that I’m now using WordPress for many projects. I’d definitely recommend giving it another look if you haven’t been using Dreamweaver for any of the reasons I’d previously mentioned.

Outlook comes to Mac, will it make Microsoft ‘Fix Outlook’?

Microsoft’s Mac Office team recently announced that the next version of Mac Office 2010 will replace the Entourage email client with a purpose-built for Mac version of Outlook. This is interesting as it suggests that Microsoft see the forthcoming Exchange support built into Mac OSX 10.6 as bit of a threat.

The current email client in Mac Office, Entourage, is a poor citizen of OSX 10.5 due to its single database that is not very compatible with OSX 10.5’s Time Machine back up function. So Entourage was at least due for an update, however, bringing Outlook to Mac at least makes things a bit more consistent between Windows and Mac Office suites. I dare say a number of Windows to Mac switchers will be quite happy to see the addition of Outlook.

Will Outlook for Mac’s HTML email support suck like it does on Windows?

With the announcement I think many web designer / developers might likely have the above question in mind! If you’re not in the habit of creating HTML format emails then you may not understand what the problem is, basically since the release of Office 2007 for Windows the rendering of HTML emails in Outlook took a turn for the worse. Outlook 2007 uses Word’s HTML rendering engine to display HTML emails, effectively taking several steps backward in regards to rendering support in modern email clients.

Due to the poor HTML support in Outlook on Windows, developing HTML email newsletters requires using HTML formatting that hasn’t seen the light of day since the heady days of the late 90’s, table based markup, very little support for CSS markup. If you want to read more about this then head over to the Email Standards Project for lots of good information, and in particular this post: “Microsoft to ignore web standards in Outlook 2010 – enough is enough”.

The Mac Office team have indicated they will make Outlook for Mac from the ground up as a true Mac application:

Outlook for Mac is being built from the ground up as a Mac OS X application using Cocoa. It will have a new database that delivers a reliable, high performance, and integrated experience with Mac OS X. Users will be able to back-up with Time Machine and search email, calendar and contacts with Spotlight.

So I’m reading from this that as it’s using Apple’s Cocoa frameworks that it will make use of the WebKit rendering that Cocoa provides to render HTML emails. As such it should have excellent HTML rendering capabilities, which incidentally the current Entourage application already has. So Mac users should have a good experience regardless of whether they use Apple’s Mail or Outlook email clients.

However, there’s a potential problem. The Windows Outlook team have so far stubbornly denied any need to fix the problem with HTML rendering in Outlook on Windows and indeed seem intent to release Outlook 2010 with the exact same rendering support. As the Outlook team seem to think that the Word HTML rendering engine is appropriate, will they mandate that Mac Outlook should render emails exactly the same way that the Outlook for Windows does? Will they make Word the rendering engine for HTML emails in Outlook for Mac?

If they don’t then basically they’ll have a potential lack of interoperability between Outlook on the different platforms, Outlook for Mac will offer good support for HTML email (as it already does with Entourage), and Outlook for Windows will suck. I’m not sure that Microsoft will be happy with that seeing as Office is one of their flagship products and will want to make the experience the same. The question is, if that is the case then which side will yield?

Email Standards are Web Standards

Regardless of your opinion on HTML emails* it’s a big issue, whether you like or dislike HTML format emails the reality is that they’re here to stay, support for web standards and good layout practices should be encouraged, regardless of whether that HTML is rendered in an email client or a web browser. The recent Fix Outlook campaign hopefully sent a strong message to Microsoft about how the development community feel about it. Let’s hope Outlook for Mac doesn’t come with the same support as it’s Windows counterpart and that the discrepancy between their rendering engines forces Microsoft to step up and make Outlook 2010 for Windows include improved support instead of dumbing down Outlook for Mac!

Update:
There’s a new site launched by a couple of employees from Microsoft, “Make Office Better”, it introduces it’s purpose stating:

Hi! We’re two Microsoft employees looking to collect customer ideas on how to improve Microsoft Office. If you’ve got a new feature idea or an idea on how to improve Microsoft Office, please share it here…and vote on other ideas you agree with. Through the magic of crowd-sourcing the best ideas should rise to the top.

What’s great about the ‘magic of crowd-sourcing’ in this case is that the number 1 Office issue that people want to see fixed is “Improve the HTML support in Outlook“. Well, they asked for feedback!

~

* And don’t say “HTML emails suck, everyone should just use plain text emails”, HTML emails will stop being used around the same time that everyone adopts XHTML 2. If you don’t like them then you can always use a mail client that can force the display in plain text!

Essential Reading for Web Designers – Second Edition

I wrote a post back at the end of 2005 called "Essential Reading for Web Designers" in which I wrote about a few books that I considered essential reading for anyone who does website design. Primarily these books focused on using web standards, at the time these books were the few key books about this subject.

Since then a lot more books have been written but the books I wrote about then are still very important. In fact two of them have been updated with a second edition bringing them right back up to date with the current state of web design. As these second editions have come out I thought I’d make a second edition of my own and update my list of essential reading too!

Cover image of Design with Web Standards - 2nd EditionDesigning with Web Standards – Second Edition by Jeffrey Zeldman

This second edition by an author who was recently called ‘The King of Web Standards’ in a recent interview on BusinessWeek.com brings this key book up to date. the back cover states:

Best-selling author, designer, and web standards evangelist Jeffrey Zeldman has updated his classic, industry-shaking guidebook. This new edition, now in full color, covers improvements in best practices and advances in the world of browsers since the first edition introduced the world to standards-based design.

View Designing with Web Standards – Second Edition on Amazon.

Cover image of Bulletproof Web Design 2nd EditionBulletproof Web Design: Improving flexibility and protecting against worst-case scenarios with XHTML and CSS, Second Edition by Dan Cederholm

This second edition, due for release in September 2007, updates this excellent book. Dan writes about it on his own website saying:

This isn?t a giant update nor a new book entirely. Rather, it brings the examples in line with Internet Explorer 7 (which wasn?t released when the first ed. was published) and adds several more examples based on ems (which were sorely lacking from the original book). There are of course errata fixes and nips and tucks throughout as well, and about 30 additional pages were added in total.

View Bulletproof Web Design: Improving flexibility and protecting against worst-case scenarios with XHTML and CSS, Second Edition on Amazon

Cover image of DOM ScriptingDOM Scripting: Web Design with JavaScript and the Document Object Model by Jeremy Keith

This book focuses on best practices for Javascript coding. It’s a great book aimed at web designers rather than programmers so it’s an excellent way to get into the power that the DOM and Javascript can offer:

The book is aimed at designers rather than programmers. If you’ve learned the benefits of Web Standards through CSS and you’re now ready to move on to the next level, this is the book for you. It will show you how to add stylish, usable enhancements to your web pages using Web Standards that guarantee future compatibility.

View DOM Scripting: Web Design with JavaScript and the Document Object Model on Amazon.

Cover image of Bulletproof AJAXBulletproof Ajax by Jeremy Keith

Following on from DOM Scripting, Jeremy Keith writes further about best practices in Javascript programming. This book focuses on how to use AJAX but in a way that degrades well and is accessible:

Using flexible design elements that adapt to the user?s needs, Web sites continue to work beyond the typical browsing environment. I believe that the same philosophy can be applied to Ajax. Far too many Ajax applications are built like a house of cards, dependent on just the right stack of technologies in the browser. Browsers that don?t support the required technologies are locked out and their users are turned away. To avoid this, you need to create flexible applications using bulletproof Ajax.

View Bulletproof Ajax on Amazon.

And many more…

These are just a few books on these subjects, but they are a few that I would definitely recommend reading, and probably in the order I’ve listed them too. A quick look on Amazon (or in my Amazon aStore found under the ‘Store’ section above) will find many other books to take your web design and development further.

~Rick