Symphonious

Andy Herron:

Tomorrow  is a day I’ve been looking forward to for quite a few years.  Dylan Just, one of my best mates from uni, is starting at Ephox.  He’s not yet on Planet Ephox but I think we’re fixing that tomorrow morning.

 Indeed that has been fixed. Welcome on board Dylan! Any other Ephox folk who want to start blogging - just let me know!

Some interesting responses to my complaint about feed readers stripping CSS:

• Nick Bradbury - Response: On Stripping Styles For Security
• Sam Ruby - Stripping Styles

There's a common misperception that my complaint was about all styles but in fact I was just referring to inline styles on the basis that they are actually part of the content, not just presentation. Sam Ruby points to a feed from Wikipedia that is exactly the use case I had in mind. Many of the comments however want to strip styles to preserve a uniform look in a "river of news" type of reader, for example Nick's comment:

The real problem isn't security, though: it's presentation (ironically). Leaving styles intact makes sense if you're reading one post at a time, but it makes less sense in a river of news where posts from multiple feeds flow down the page. The purpose of a river of news isn't to retain the presentation of any single post, but instead to provide a common presentation for all posts, making it easy to pick out the ones that interest you.

If you don't download external stylesheets (which probably aren't referenced by the feed anyway) there's a very good chance that the resulting presentation will be consistent, without stripping out important visual information. Even if you're reading one item at a time rather than a river of news, it's far more efficient for the styles to be consistent so I doubt there's any real call for rendering entries the same way they appear on the site. Consistency is important to everyone, but data loss should be a concern for everyone and right now we're losing a lot of data.

Nick also commented that preserving styles while maintaining security isn't too difficult and Sam Ruby and Paul Querna pointed to the sanitization rules wiki page, so the technical challenges seem to be solvable, but there's still one problem: users. The thing is, people too regularly abuse HTML and use inline styles for presentation rather than just visual data either from a lack of understanding or a desire to push their advertising. How do we solve that?

The first line of defense is to remember that feeds are opt-in, if people misbehave and push advertising or generally do annoying things in their feed you can easily unsubscribe. Social pressure is always the best solution but it's not 100% effective so we'll probably need some technical measures as well.

The second line of defense unfortunately is likely to be user preferences1. It's important that they are available on a per-feed level so that you can disable styles in feeds that do the wrong thing, but preserve the visual data in those that get it right. I wonder if there are a few simple heuristics that could be applied. For example stripping any style that's applied to the entire content would fix the common case of people using inline styles to change the font face or size instead of just adjusting their stylesheet. I'm sure there are a few other simple rules that could be identified to prevent the most common abuses of inline styles without having to strip all CSS.

I'm glad there's some discussion of this beginning as it's the only way we'll find good solutions that let us keep the benefits of feeds that we have and expand on them by leveraging newer technologies.

1 - unfortunately because complicating software by providing more options is never ideal↩

I got some really positive feedback on the various community/openness projects that I've been spearheading within Ephox from one of our OEMs today. Apparently they've discovered our early access program and are already trying out our brand new Express Edit functionality1.  It's really nice to actually hear from clients that these elements are useful as we haven't really managed to build up a community, even if we are seeing gradually increasing traffic. For a while now we've had potential new employees commenting on Planet Ephox which is great, but we haven't really heard from clients taking advantage of it, even if we've seen some of the indirect effects via analytics and support cases.

Now getting great feedback from one client is satisfying but it's not the end game - of course we want to impress all our clients like this by whatever means it takes. What I find most exciting about this is that it demonstrates to the sales and marketing teams that our openness and even our engineering practices2 are actually valuable to clients, particularly OEMs where the relationship is more important and long term. The business users and product managers probably don't care about automated tests and early access, but the engineers that have to actually integrate our product do. If we can provide them with tools like the hints and tips on LiveWorks! or early access to new features, they can better integrate our products and get the most out of them for the actual end users. In the end, that's what everyone should be working towards and we can and will help out on multiple levels.

1 - Don't forget to let us know how it goes and how we could improve it btw….↩

2 - continuous integration, TDD and all the other things we do to ensure quality↩

Mindy McAdams gives advice about how students should test their online page designs, the trouble is the statistics she's looking at are lying to her.

You can see that although the screen resolutions larger than 1024 x 768 add up to more people (4,512 vs. 3,524), the single most common resolution in use (among people who read this blog, that is) is 1024 x 768. You can also see that the number of people viewing the site at the old standard, 800 x 600, is quite small.

Conclusion: It is sensible to design this blog to look good at a resolution of 1024 x 768, and to test it at some higher resolutions to make sure it doesn’t become unusable.

This is wrong - just because people have a screen resolution of 1024 x 768 doesn't mean they are using all of it for viewing your web page. Once you get to screens that big it's quite common for people not to maximize the browser window, so the actual page rendering area is much smaller than the screen size would suggest. Additionally, you can't assume that people have the stock standard browser install anymore - there are a huge number of browser toolbars that people wind up with (often preinstalled) that take up screen space, not to mention people who read the blog in a feed reader with a list of feeds down or tabs down the side.

While there might be some merit in tracking your user base and designing to the majority, you need to track the size of the actual page rendering area, not the screen resolution to get any idea about what your users will see. The best approach however is to design a site that scales well from small screens up to larger screens as gracefully as possible.

Moving on to browsers:

Conclusions: Web pages must be tested in at least three browsers: Firefox, IE 6 and IE 7. Pages for this blog should also be tested in Safari, although that may not hold true for all sites (see below).

Seriously, test in Safari - even if only the Windows version. Once you get your pages to work well in Firefox and IE 6, you've done 99% of the work to get it to work pretty much everywhere. While you're there, test in Opera too. Why limit your audience when you've done all the hard work to get the design to work cross browser anyway? Either design for one specific browser to minimize the effort required, or design for all of them - the second browser you support is the expensive one, once you've got that you may as well have them all.

So how should students (and professionals) test their online page designs?

On as many browsers and platforms as they can manage. You never know what configuration your next paying client might have and you want to make sure the site looks great for them or they'll pass you by. Numbers and statistics don't matter - that million dollar client counts as one hit just like the millions of people you don't care about. Don't miss your chance by being lazy.

I have to agree with "Jon", Gruber (John with a h) does have a habit of linking to sites that link to him regardless of how good they are. For instance, this link list entry was a complete waste of time…

I wonder if there's any limit to it?