Design a developer friendly web

A few years ago, I've started creating a list of features, that web-browsers should be able to do, to build rich Internet applications without complicated tweaks and hacks. The time passed away and nowadays, many creative heads concern on web-development, thus some of my ideas landed in HTML5 or other web-standards, without my help. So, I want to show an extensive collection about techniques of browsers, which are already implemented, and which are still needed for developers to design the Internet of the future.

Since the early beginnings of the Internet, many things had happened. The Internet is used as encyclopedia, communication- and gaming platform or as a shopping center. The whole progress has in common, that everything will be more interactive and more networked. Because the Internet were usually used for publishing scientific documents in the early days, the standards have been adjusted to the present requirements many times since that day. The development speed of web-browsers and other web related technologies were quite straightforward until the Web2.0 era, but the revolutionary idea of the Web2.0 has brought forth a lot of Internet platforms, which had other requirements than before; this is what this article is all about, and what the rich Internet application makes so interesting.

I've seen a lot of technologies come and go in the last 10 years of Internet usage, I had joyed a lot and I'm happy about the actual level of development. Actually, I'm backend-developer from the bottom of my heart, but sometimes I have a phase of play, which recently resulted in a couple of HTML5 eperiments. With the last experiment, I tried to project a simple 3D application with the new canvas element. Most of the other experiments, like they are available on my projects page, are also kept really simple and do not only have the purpose to be illustrative material for a common audience, but rather I tried to examine some things of it's feasibility. I think I can now judge, where we stay today and what's still missing.

HTML5 has already triggered a very good movement in the right direction, but the most important point will be to bring all common used browsers to a uniform level and to enforce the usage of strict web-standards without compromises. This would be possible with, e.g. a shared open browser engine, which is developed by Microsoft, Apple, Google and Mozilla as well. Microsoft would also be in the position to replace all older versions of Internet Explorer from Windows platforms - assumed they are using the update functionality. Finally, all browser developers will just work on an individual GUI for their product, and the core of the browser is kept decentralized with a full shared feature set. Let's call the project Open Browser. The only remaining question will be, weather we would have the same development speed like the actual race between Firefox, Chrome, Opera and Safari.

But let's state a design vision of future browsers with a start including some ideas of the past, which are already implemented and help on the way to get a better user experience. One might even say, that we've already achieved a little part of the future.

Extend type-attribute for input fields

A wish, I had for a long time, is that input fields get more flexibility in the behavior of more types and functions. JavaScript allows to build rather every input type, but having such functionality cross-browser valid by default will really help web-developers. Especially, because there is only a limited range with needed types, such as Emails, telephone-numbers and so on, or the more complex types like sliders or dates. Such types are also a good idea, when it comes to build applications for mobile devices, where a small display limits to show the whole keyboard at once. If you know, that the input field is an Email address, it's quite sufficient to show a keybord with alpha-numeric keys, a point, underscore and the @-sign. This way you can really improve the user experience, because they will better learn to use these standard elements instead of learning every new input element on every small website.

Hardware acceleration

I think, one of the biggest problems of Microsoft is, that they only concentrate on a small range of things which result in a negligence of some major problems browsers have these days. This problem, Microsoft has, is also shown with the new IE9, which is better than the previous versions of the Internet Explorer-family, but is inferior, if you compare it to browsers like Chrome. Nevertheless, Microsoft's decision to focus on hardware acceleration in their new browsers is really good. Also to standardize this functionality with Direct2D is a good movement - even if Direct2D is closed and reserved for Windows platforms. V8 (Google Chromes JavaScript Engine) generates also really fast predefined machine-code, but can not beat Microsofts attempt to use the faster graphic instructions of the GPU.

Implement a method of word-wrapping in the browser

On YouTube, I firstly explored, that they implemented a really simple way for wrapping comments, in which some Crabby wrote things like "NIIIIIIIIIIIIICEEEEEEEEEEEEEEEEEEEEEE" or similar, by inserting white-spaces in a specific distance in these words, because otherwise the whole layout would be disturbed. It doesn't really look quite good, but it serves its purpose. Times ago, I had the idea to implement an entity tag like       or  , but which will only break the line, if it's necessary. A workaround, that works with some newer browsers like Chrome and Firefox could look like this:

<span style="position:absolute;left-999px;"> </span>

A more better way for wrapping long words or phrases is now implemented with the CSS3 attribute word-wrap: break-word, with which a word-wrap is possible without a server side pre-formatting.

Standardized multi-upload

Multi-uploads are easy to implement. Take twenty input fields of type="file" and let the user choose every file separately through the usual file-selection menu. Those of you, who uploaded holiday pictures that way, know how funny this can be. This is not only horrible in view of usability, also in a technical point of view are some problems, as the upload size increases. Computing such a packet on the server is the next problem. Much better will be an asynchronous standardized multi-upload or directly an ...

Asynchronous multi upload with drag'n drop

The most intuitive handling of file uploads would be drag and drop directly to the browser window, or textareas inside of the browser window. This way, the user has the lowest latency, since the upload can begin asynchronously, even when the user, possibly, chooses other pictures on the hard drive for uploading.

Update from 10.11.2010

The drag&drop API of HTML5 offers the event.dataTransfer.files attribute to get files, draged from the operating system. A demo can be found on HTML5rocks. Then we only need to upload them. Are there any security restrictions?

Upload-progress

Because the upload is the most stupid thing in today's web-browsers, I have to start a third headline about this topic. Sure you can use some Java tools or Flash, but this can not be the solution for future web-sites. Developers of larger communities like facebook, built upload managers for their own site as a browser extension to correct this drawback now.

A feature of browser integrated "upload managers" should be a hook for JavaScript to get status information about the currently running upload to be able to visualize the data in form of a progress bar. What is normal for downloads, is really hard to implement for uploads. As a result, impatient users are clicking many times on the submit button. To forbid such playing-attempts, you can disable the button after the first click, but this makes users also not happier. Some server side programs like lighttpd and PHP have extensions for getting information about the currently running upload via AJAX, but drawing a progress-bar is NOT a server side problem, as all information about the upload are already available on the client.

WYSIWYG element integrated directly in the browser

As I talked about drag and drop multi uploads, I indicated that intelligent input opportunities should be developed for browsers to let textareas be the destination for file-drops. I could imagine, that such an textarea consists of some API method's like <video>, <canvas> and <audio> of HTML5, but looks like an editable <div>, in which I can access the value attribute, to get the inner text, but also have the possibility to access the whole formatted HTML-code via innerHTML.

Browsers completely without plug-ins

I'm flash developer since version 3. However, I think such plug-ins are only a temporary solution, since the standards at a particular time did not cover the the technological needs. Now, we have HTML5 which makes many dusty technologies obsolete - in theory. From a technical view, I'm totally behind Steve Jobs. Todays plug-ins are relics, because the Internet has to be open. If Adobe is now struggling to keep these relics living to legitimize the Macromedia-mispurchase it would be really sad for such a technology company. If Macromedia Adobe need work, they should open up a new spectra of tasks, like building a HTML5 editor. The scope to distribute such a tool is still given. The same goes for PDF. In general, I like PDF for it's compatibility and that it is a read-only format, which makes it nice for some important documents. On the other side, is it necessary to have such loading times for a simple document, these days? Luckily, there is scribd, which experiments with CSS3's @font-face to make transformed PDF's look the same in plain HTML.

Unfortunately, we still need plug-ins like flash for a small range of things. Hopefully, these things will also be added (or even fixed) directly to the browser in the near future:

Transparent browser windows

To see the Internet more and more as an independent application without need to have a feature full operating system behind, opens the question, if it is a nice idea to build cross-plattform applications over the Internet, only in JavaScript. The idea of Java is nearly the same, to be platform independent, but the decentralized model of the Internet opens much more possibilities. To be more integrated in the operating system, hiding the main browser window would be a good idea. Adobe AIR's idea goes in the same direction, but as we once started to punish Adobe, let's proceed.

One of my first HTML5 Experiments was the Winamp-Equalizer experiment, where I took a screen of the Winamp user-interface and animated the equalizer. Now imagine, that this app is fully functionally and without the browser window around it. No one would think, that this is inside of the browser.

Another cool feature would then, to use the favicon of the browser-window in the task-bar of the operating system.

Fullscreen browser windows

There are so many cool things implemented in pure JavaScript these days. Complete 3D-game engines like Wolfenstein or even video players and widescreen-able applications. With hardware accelleration, the browsers should also be able to handle a fullscreen rendering, to play videos in a cinema view and play games like real computer games. Maybe WebGL will bring the power to the browser to develop real computergames in JavaScript, without performance loss. This is really sound of the future, but implementing a hook to bring the browser to a fullscreen mode would be really helpful.

Accessing raw information of the new audio tag

With the introduction of the <audio> tag, some small demonstration media players were already developed in pure HTML, all cool and innovative. But compared with, e.g. Winamp, they lack on something: the visualization. As I said, I implemented a really stupid equalizer, which uses random data to be visualized. It would be nice, to have such an equalizer with real data.

A Firefox hacker has recently published a test to compose songs with pure JavaScript. I think, when we go this way further, we can use the API also for reading information about songs. Accessing id3 information would also be cool, to round out the audio tag's functionality.

Update from 03.09.2010

My wish to read raw information out of the new audio tag may have been heard and implemented, at least in the new Firefox 4.

Browsers should operate with certain modes

Although, there was implemented the X-UA-Compatible mode in modern Internet Explorers, but I do not mean such rubbish with the headline. I mean much more a CSS-mode, to put the browser in a certain default mode for layout processing. Many CSS files nowadays begin with a huge amount of CSS-reset-code, which only serves to zero all elements. Better would be a mode to tell the browser, how the initial-setup has to look like. So, every browser can reset all needed elements, without having been eclipsed by a lump of CSS in the right direction.

Completely cachable layouts

The layout, no matter how optimized it is, has to be transmitted to the client with every request. Of course, we do not use <font family="Verdana"> anymore and CSS and images are really hard cache- and compress -able but the overhead for the transfer is still given - even if the request results in a 304. If you have an application, which only needs to update parts of the site, you can transfer needed information via AJAX and embed it via DOM-Scripting.

My future dream for websites, which have to load the complete content instead of loading just small parts anew is, that we completely develop websites in XML and transform it via XSLT to HTML5. Then, we'll embed CSS and to complete this idea, we could bundle a package like Mozilla's .xpi file for browser-extensions to deliver the complete layout with all styles and needed layout images, already compressed. Only one request (which results in a 304) is needed in further clicks.

Using XML is also a good idea to have semantics in the data transfered.

Ship JavaScript libraries with browsers

JavaScript-desireless-carefree frameworks are trendy, but on the hindsight also really traffic intensive, besides the rest of the layout. For example jQuery can be retrieved from some CDN's with different speed. But, even that is not a clean solution, as the requests are still given. The positive aspect is, that using a shared CDN raises the chance to get a cache-hit over different sites. But why not embedding the, let's say, 3 most common used JavaScript frameworks, like jQuery, Prototype, MooTools directly to the browser? An inclusion could be made under the usage of the chrome:// URI scheme like this:

<script type="text/javascript" src="chrome:///include/jQuery-1.2.2"></script>

No browser-specific CSS attributes

Today, every browser has elements, that were implemented for demonstration purposes only to get it sooner or later standardized . Thus, there is now a confusing bevy of -moz-* and -webkit-* attributes in CSS, and also some unstandardized HTML tags, where it is not said, that they will not be removed in future versions, and whether they are eventually ignored by other browsers. The better proposal would be to submit the ideas to the w3c, which would of course respond more quickly to new features and adapt the standard where it is necessary. Mozilla's previous extensions known as min-height, min-width and position: fixed, seem to be accepted without begging the w3c, but this is a miserable gradual process, that the today's development speed no longer allows.

Tabs under the same domain should be able to share data

To me, it often happens that I opened different tabs or windows of the same domain. From a developer perspective, this represents an interesting case, as you can synchronize tabs, with no need to ask the server for new data. A good example of this is the chat on facebook. If you surf on facebook with different tabs, a persistent link to the chat server is present for every tab. If the tabs could communicate, this could be optimized by getting the data directly from another tab instead of accessing the server. Then the tabs only have to arrenge, which one is the listener and which the sender.

Relative click-position on elements

A very silly thing is, that the click coordinates for each element in the DOM are the absolute coordinates. If I really need the absolute coordinates, I would add the click event-listener on document, but if I have an event listener on a div inside of the DOM, the probability is very high, so that I need the relative coordinates within this <div>. Changing this behavior can disturb some applications, so what's about hearing on the attribute position: relative on the certain element. Then, we have our backward-compatibility and can change the mode of an element with a simple piece of CSS.

Extend CSS to be nestable

When I started to develop my own CSS optimizer, I got the idea to nest definitions, to reduce the selector size and also bring a bit more logic into CSS. Sometimes I have the problem to keep the savvy, when the file becomes bigger. If something like this:

#comments {
	padding: 10px;
}

#comments > div a {
	color: red;
}

... could be written as this:

#comments {
	padding: 10px;

	> div a {
		color: red;
	}
}

... the whole thing would be readable and makes it also straightforward for optimizing/compressing tasks so much more.

Update from 09.07.2010

This wish/suggestion should be obsolete with lesscss.

Finally, what we need for future development

The Internet has become a big application, in which new functions outperform themselves over and over again. The browser is today the gate to the world. A few years before, browsers only had the job to allow simple information retrieval and to let users communicate - but even not that, because the classical Email was too much popularly instead of using direct messages in communities, chats or something else.

Today a browser is an interaction medium, which requirements continuously grow. I'm really not sure, if this task can be tackled by a small team. Look at Mozilla's bug tracker, and you know what I mean. Probably the most perfect development for the Internet would be a decentralized organization, as I already said. So the core developers of all major browsers could develop on one perfect backend for all browsers. Thus, all browsers would have the same rendering engine, problems and misinterpretations of spec's would be a bad thing of the past.

Because the development progress of the browser engine would be very fast therefore, it would be annoying to ask the user for every update. Incremental updates should install itself in the background and would not interrupt the user in any task. If you bundle many things into the browser, like JavaScript libraries, the update cycle would indeed another than before. Of course, should the browser be updated to a complete new version, the user can be asked. Many users would ask: Why should I? Then make use of the psychology behind group dynamic processes and underlay the marketing strategy with something collective like "20,000 sites already using the feature to backup your facebook account on the moon. Upgrade to Firefox 5.0, now."

I know, some things of this article are utopia, and for the next 5 years we have to fight against old browsers from anew. Now we've dropped the support for Internet Explorer 6 from almost all major sites, but how many clients still support HTML5? I hope the one or the other wish in this article will be implemented in the near future. If you also have ideas to improve the functionality of browsers, feel free to missuse the comment box :-)

You might also be interested in the following

1 Comment on „Design a developer friendly web”

Miami Web Design
Miami Web Design

I have an idea about browser compatibility. Stop making sites work for old versions. Make it well-known that you should keep your browsers updated, just like you have to keep your computer updated or your car even.

Switching from HTML5 to the next version isn't as big of a deal. That's up to the website designers and if a website owner finds it worthwhile.

I'm looking forward to HTML5. Oh and I think by the time HTML5 makes its full fledged renovation, it will take about 5 years.

 

Sorry, comments are closed for this article. Contact me if you want to leave a note.