Emails, blogs, or wikis - it's just permissions

The only difference between emails, blogs, wikis, and notebooks is permissions.

See the table below, which lists the document type, view permissions, and add permissions.

View	Add	Document
private	private	notebook
private	public	email
public	private	blog
public	public	wiki

Other than that, they can use exactly the same technology (RSS / Atom), and exactly the same authoring WYSIWYG methods.

Currently, they're all separate tools - I can't see that continuing. We're likely to see integrated online authoring suites to handle all of them together.

Internet Geometry

Web page layout, in HTML, follows the CSS box model. This assumes that everything on the page, including the page itself, is a box with vertical and horizontal sides - paragraphs, images, sections, text, etc.

This works pretty well until you try to include vector graphics - circles, curvey lines, polygons - and effects like rotation and skews. So SVG has defined its own, more sophisticated layout model based on absolute positioning and coordinate transformations - CSS can't be used to place SVG elements.

The SVG layout model is usually considered unimportant in its own right - the real emphasis is on SVG's elements, like circle, line and polygon. But I think differently - it transforms the internet's geometry.

SVG layout transforms HTML
The SVG layout model provides the missing pieces to the HTML layout model - rotations, skews, scaling, and length units.

After all, I might want just SVG's geometry, and not its elements (circles, polygons, etc). Consider the following compound XHTML / SVG fragment, which shows rotated text. Not possible with just HTML!
< h1 svg:transform="rotate(90)" > Hello < /h1 >

And how about the following use
< img svg:transform="translate(5,0)" src="http://www2.blogger.com/image.jpg" width="50%" / >
which finally allows web designers to offset their elements by an absolute amount (five pixels along the x-axis) from a percentage.

SVG and HTML layouts can even work together:
< img style="left: 5px;" svg:transform="rotate(45)" src="http://www2.blogger.com/image.jpg" />
The renderer should rotate the image, draw the smallest possible horizontal box around it, then place the left hand side of the box five pixels from the margin.

Note that for now, Opera, Firefox and Safari are all using the SVG foreignobject element to control transformations, rather than allowing simple use of the attribute as above. This seems bizarre to me - all that should be necessary is a namespace declaration, as per the examples above.

For the future: CSS4 and curvilinear coordinates...

CSS was designed to ensure independence of content from presentation. It's used to control HTML page layout.

For some reason, the SVG authors thought differently - there's no SVG CSS styles to control layout. But you can think of the svg:transform attribute as a super-powerful CSS positioning style. Adding it to CSS4 would introduce consistency and extra power for managing layout on the web.

And most proprietary graphics tools provide something that SVG can't - the ability to squish and distort images, like those curvy mirrors at the fairground. That's because SVG currently only allows linear coordinate transformations - i.e. rotations, translations, and skews.

More general curvilinear transformations could be added quite simply to SVG - for example, allowing radial coordinates. Apart from squishing images, this can be very useful to define paths - consider:

< h1 svg:transform="x,y + sin(x)" > This text fits to a sine wave < /h1 >
which fits HTML text to a sine wave, by mapping the x axis to itself and the y axis to the wave. Today, you can't do this with HTML text, and to do it with SVG text you would have to calculate a series of points on the path and then interpolate between them.

Geometry is important
Basic geometry might be more than two thousand years old, but it's still the foundation of graphics. SVG transformations can provide extra impact to web pages and much more freedom in placing elements. What's needed is a joined-up approach that combines the best of HTML and SVG layouts.

Records Management

In many industries - especially financial services - there are regulatory requirements to store data for various time periods. Examples include customer records, transaction records, financial statements, and even emails.

This adds up to a huge administrative challenge. Millions of records are created by many different systems - each has to be categorized, stored, regularly reviewed, available to retrieve at very short notice, then deleted as soon as the time period is up. Of course, in the meantime the legal definitions and time periods are regularly changed. And if you get it wrong, you're in deep trouble with regulators and establish a reputation in the press for bad management.

Part of the issue is that records exist in so many places - paper, database tables, email archives, file shares, mainframe storage. Every record should be tracked and tagged with a category, a creation date, an owner, and an expiry date.

Records Management on the web
Of course, a growing proportion of these records are now online - and this presents huge advantages:

• The URI: finally, a universal way to locate records.
• HTTP: a simple technique for transferring records, including standard descriptive headers
• Search Engines: sophisticated technology for crawling for records and for retrieving them
• HTML: a text format for records that can be quickly scanned and analysed, including meta tags

And of course, the web includes a cacheing system to manage expiry dates on every record.

There are two basic conclusions.

Firstly, you can expect Records Management Systems to become more and more like search engines - crawling the intranet for records, analysing them, categorising them, and flagging them when their expiry date is past.

And secondly, the best way to implement a records management solution is to migrate systems to the web - the basics are all built in!

Adobe's internet strategy

Adobe occupies a unique position in the market. With a focus on desktop graphics technology, it has also branched out into document workflow (Acrobat) and website design (Dreamweaver).

This focus on desktop applications is a weak point. As applications migrate to the browser, Adobe will have to change to avoid being taken over by internet-based competitors. So far, its attempts to cater for the internet have ranged from the hugely successful (Flash) to the barely begun (Photoshop).

So I've tried mapping out what Adobe should be like in a couple of years, after executing an ambitious internet strategy.

Adobe the hosted service provider
You can imagine logging on to Adobe.com (or your hosted site), viewing and uploading your videos, images and websites, and editing them online via your browser.

This takes Adobe beyond Google's YouTube and Picasa, by enabling online editing and private hosting. And Dreamweaver is replaced with a website hosting service, where professionals can log in and edit the site.

But end users will also log in to create their own webpages, like a blogging tool that enables images, tables, columns, videos, etc. This is the word processor of the internet age - a massive opportunity, and it should be a core competency for Adobe.

I've also decided that Adobe should lose its proprietary PDF file format, in favour of standard HTML and SVG. There are only three reasons why PDFs are popular - because everyone can read them, hardly anyone can edit them, and their conversion from other file formats (e.g. MS Office) is high quality. But everyone can read HTML and SVG / VML too, website permissions can be more tightly controlled, and Adobe can re-use that file conversion knowledge on their web hosting site.

Adopting an internet strategy
Here are the future products:

• A browser plug-in for playing video and audio
• An online hosting service for video, audio, and images (both raster and vector), with integrated online design functionality.
• Offline desktop versions of the video, audio and image design tools (useful for editing large files)
• A website hosting service, with integrated online website design tools (including a service for perfectly converting old office documents to webpages)

Here are the products it should no longer sell

• Acrobat reader - the PDF format is replaced with HTML and SVG / VML
• Desktop web design tools e.g. Dreamweaver
• Flash vector graphics - vector graphics are handled in the browser by SVG / VML

Massive opportunity
Because the industry is changing so quickly, there are massive opportunities in Adobe's market. Adobe has a lot of valuable experience - such as file format conversion, graphics technology, and website design - that will stand it in very good stead.

But to take advantage of these opportunities, Adobe has to adopt an internet strategy of moving away from desktop applications towards a hosted model.

Google, Silverlight and Apollo

So, as predicted, Google have announced online presentation software, and it's done using SVG and VML. You can see a sneak preview at http://ajaxian.com/archives/tonicpoint-ajax-powerpoint-with-svgvml

This makes the race for graphics plugins - Microsoft's Silverlight and Adobe's Apollo - hard to understand. If they're not needed for the highest profile web graphics application, then what are they for?

Well, they'll both play videos and audio. It makes sense to treat these as plug-ins, because they rarely have to interact much with the rest of the page.

Mixing Vector Graphics with HTML
But for vector graphics - circles, lines, shading, rotations - plug-ins are a red herring. You need the browser to handle vector graphics directly, because you need it to be seamlessly mixed in the same document as HTML. That way, you can:

• mix and match HTML elements (e.g. fonts, bulletpoints, linebreaks etc) with additional graphical elements (circles, lines, shading, coordinate transformations) to enabler richer web applications
• share the events model - to seamlessly respond to user events (e.g. an SVG slider controlling an HTML form)
• share javascript and DOMs - adding, modifying and deleting nodes, or using Ajax, to create interactivity between any elements on the page
• share CSS, to style your site consistently

No plugin could ever satisfy these demands, all of which are required to produce web presentation software.

The web graphics market
Funnily enough, I think management at Adobe accepts these arguments. It's just that they don't have a browser, so they have to rely on plug-ins (which are quickly become very similar to a browser) until they find something else - likely improved designer tools for creating SVG / VML websites.

Microsoft have tried the other route - of replacing SVG / VML and HTML with a new language, XAML. But even an all-powerful monopolist won't be able to fight against the internet.

It's a myth that vector graphics in the browser are weak. They're good enough to produce presentation software, and they're getting better - SVG support is getting even better in Firefox, Opera and mobile devices, and Safari is gaining SVG support in the next release.

SVG / VML is the future
If you're considering writing a web application that requires vector graphics, you shouldn't worry about Apollo, Silverlight, or Flash. Just mix some SVG and VML in with your HTML. The technology already exists, it works fine, it provides the best possible integration with websites, and it won't go away.

Scrolling versus Paging

When it comes to the oldest war of the technical formats, you can forget VHS versus Betamax. There's one still raging after more than three thousand years - scrolled versus paged document displays.

Ancient and Medieval documents

In Ancient Egypt, display technology was based on papyrus - the long thin reeds lending themselves to being rolled up into scrolls, rather than sheets. But papyrus decomposes quickly, especially in colder climates, and the Romans invented parchment in the first century BC, made from animal skin, which was more easily folded into paged format.

Parchment was of a more consistent quality, and kept better, but a key advantage was its accessibility - it's much easier to quickly turn to the middle of a book than to the middle of a papyrus scroll.

But pages really came into their own when the printing press was invented, back in the 1400s. Pages could be much better printed on than scrolls, so the quality and efficiency of pages lept ahead of scrolls for more than five hundred years, especially with standard page sizes.

Pros and Cons: the 1950s

I'd summarise three reasons why, by the 1950s, pages were winning the war with scrolls

• Lower costs, higher quality - due to the printing press
• Better accessibility - easier to 'flick through' a book than a scroll
• Standard formats - e.g. letter, A4, and broadsheet sizes introduce economies of scale

Office Computers

The first office computers didn't really challenge the culture of pages. Word processors and presentation software are both inherently paged, because they're designed to be printed onto paper.

But there was a problem - users had differently sized monitors - so in order to fit the page properly on the screen, scroll bars were added.

And computers began to be used in new ways. No amount of paper can replicate automatic formulas in spreadsheets, and emails are not constrained to a certain page width and height. Spreadsheets and emails are scrolled, not paged (that's why they are a pain to print out).

Browsing the web

Most obviously, the web has changed our culture towards scrolling. Browser makers rely heavily on scroll bars and re-arranging content to fit screen size, especially as the mobile web increases display diversity.

There are some interesting exceptions. Google search results are paged (with the top 10 results on the first page, the next 10 on the second page, etc), but this is done to prevent massive amounts of unnecessary data reaching the user, rather than to fit to a certain page width and height.

And many web designers stick to the old mentality, deliberately forcing layout (particularly width) to a certain size. Lazy designers create flash animations or tables that are too big for many screens.

On the web, the word "page" is often used to mean "the document at a given URL". But it's not usually a page, it's a scroll.

Pros and Cons: the 21st century

Nowadays, the cost and quality of paging software is equal to scrolling technology - it's a simple matter of fixing some of the code. Several other factors are more important, and it's clear that scrolls have the advantage:

• Accessibility - it's easier to 'flick through' a scroll than a page, and it's also easier to adjust to user needs (e.g. increased font size for the visibilty impared)
• Screen diversity - screens come in such a variety of shapes and sizes that forcing a fixed page width and height will inconvenience many users

There will always be a few exceptions that prove the rule - for example, pages to browse Google search results, or niche applications designed for a small set of users with the same screen sizes.

But it's clear that two thousands years after their last peak, scrolls are once more the leading display technology.

Music and the URL

A report in today's Financial Times claims that the market for music CDs is collapsing, and music industry revenues will fall for another two years before digital sales finally improve matters.

The industry has been through this format change cycle several times before; most recently with the move from LP to cassette tape, then from cassette to CD, now to the iPod and iTunes.

But the distribution model hasn't changed so much - consumers purchase the songs and store them in their collection for later playback (either physically or on their PC). This model is the root cause behind some familiar woes:

• Digital Rights Management (DRM) and rampant file sharing
• Inconvenience - endless synchronization issues between PCs and each personal device
• Difficult format changes every decade

It's time for a change, because now we have the ultimate distribution model - the internet - which changes the rules.

I don't think that any music should be stored by consumers. Instead, it should be kept centrally and downloaded on demand whenever consumers want to listen. That way, consumers can not only purchase tracks - they can rent them, or subscribe to a library, or any combination of the three.

Imagine if every track had just one URL - e.g. www.beatles.com/lovely_rita.mp3 - and every time you wanted to listen to it, you had to visit the URL. Your hi-fi, your phone, and your MP3 player would all be connected to the internet. To save re-downloading favourites, you could just request the HTTP head to confirm permissions and the latest version.

Using URLs neatly solves the problems above. The tracks can be accessed from any device, using the same online account. Consumers can't copy and share tracks, because they don't hold them. And format changes are just a matter of a simple internet download.

There are only two things in the way of this model, but they'll surely be attained within a few years.

• Internet Access - every device has to be connected to the internet, at live music speeds. It will take several years before this happens; the iPhone will have Wi-Fi, but not 3G.
• Trusted Cacheing - browsers have to prevent users from independently accessing cached files.

iPods may have revolutionised the music business, but they're also the last vestiges of the PC model - storing data on the C: drive.

It may take longer than two years, but eventually music will become a true internet business.

Only then will the music industry be able to profit from long overdue new business models.

The homepage problem

There are lots of homepages out there - e.g. Windows / Unix desktops, browser homepages, Google personalized homepages, phone & PDA homepages - but I've never really seen one that satisfied me.

This is partly due to the offline / online schism. My windows desktop doesn't show my online documents, and my Google homepage doesn't link to My Documents and the Control Panel. The taskbar competes with browser tabs for flipping between applications. The start menu has been totally left behind by web applications.

But it goes deeper than that. My phone homepage has 12 clear pre-defined options - phone, calendar, contacts, etc - but desktops can't seem to do this (since Windows 3.1, anyway). Desktop icons are much too vague - every web link has the same icon, of my browser. And we can't give a consistent user experience - every different computer, PDA, and phone has a different homepage, even for the same user.

The only real solution is to further integrate the browser with the operating system. This may bring back bad memories of Microsoft in the 90s, but the internet has changed the rules again.

I've listed five recommendations to address the homepage problem:

Reclaim the browser homepage Your browser homepage should be the same as the desktop homepage - you shouldn't be allowed to change it to anywhere else, whether Google or Myspace.

Standard homepage options On the homepage should be a standard set of options:

• Favourites (editable)
• History (with options to delete it)
• News feeds (editable)
• Browser options (editable) - e.g. view settings, security settings. Some of these will take you to other web pages for more detail.

Replace icons with thumbprints and widgets Today's icons have had their day. It no longer makes sense to store five word documents or websites on the homepage, with no visual way to distinguish between them.

Instead, use thumbprints to show the contents of a documents. Keep the description or filenames underneath the thumbprint.

Another common use of icons is to open an application (rather than a specific document). Internet applications, such as Gmail, Skype and Flickr, should be allowed to display widgets, rather than just icons. These will appear as mini homepages in their own right, highlighting important information and allowing the user to click to open the application to explore further. For example, Microsoft may create a widget on the homepage to cover the basic Office Suite, showing recent documents, highlighting important features, and graphically advertising the applications. Best practice would be to allow the user to select from large, medium and small widgets for each application, to control real estate.

Links to files and control settings (in HTML)

Also on the homepage, there should be hyperlinks to take you to windows explorer, help pages, a comprehensive list of local applications, the control panel, and various widgets.

All of these should be in HTML format, so they open in the browser. This includes windows explorer, as per Google Desktop, so that it can show web content alongside local content. The objective is to improve navigation (those forward and back keys), make the user experience more consistent, and allow web content to be integrated with local content.

Use RSS feeds to synch homepage

All items on the homepage - whether thumprints, widgets, or user options - should be stored as a set of RSS (or Atom) feed, and synched with an internet provider selected by the user. When offline, the locally cached version is displayed. When online, the fully up to date version is displayed.

The homepage problem and the internet
There's no doubt that no one has really solved the homepage problem yet. The answer lies in bringing the power of the web to the desktop.