Saturday, 26 February 2011
Dealing with the Mobile Webspace
Web Design and Mobile Devices.
The Problem
I believe that it's an important area, one that should have the attention of every web designer whose work is not limited to office intranets and other dens of iniquity. It is a widely accepted fact that content is increasingly consumed through mobile devices, some have even questioned the long-term prospects of desktop computers for casual users. This makes it all the more frustrating that designing for the Mobile space is such a patchwork.
I always work to published standards (or reasonably stable drafts), as I believe all designers and developers should. I miss the xhtml2 project, but I do like HTML5. CSS3 is a dream come true, or at least it should be.
Since CSS2.1 the standard has included 'media queries' that should allow a designer to specify certain sets of rules depending on the display media in use. Considering what a boon this could be, I wonder why it does not find better support in the mobile space!
In point of fact, I have come across an excuse or two. The one that seems to really explain the behaviour that I have seen is the problem of poor implementation by designers: It seems that up until now many of the few designers who bothered with handheld styling at all were so lackadaisical that the results convinced mobile browser developers that the handheld rules were best ignored. I dread to think how badly they must have been written.
Many mobile browsers, notably Opera Mobile, now render non-handheld styles by default. So ingrained is this behaviour that the browser engine actively chooses '@media screen' as distinct from '@media handheld'. I have read that the reason for this is to provide users with a better browsing experience based on the more supported screen styling.
It probably works for some websites, even on a mobile phone. On a tablet it's likely no problem at all. But, for a layout that tries to be artistic, that spreads itself against the available screen width (note: It's important to make sure that a layout will resize to suit the widest possible range of displays.) it can be simply silly! Especially with a page designed for a landscape aspect ratio and accessed in portrait.
So it becomes necessary to replace certain rules. A browser that's ignoring handheld styles robs us of the obvious, most standards-compliant route. There is a pretty good solution though, so long as we have support for other media queries allowing the use of different rules depending on screen width and other features.
We can then use those media queries to activate certain features for large screens and others for small screens, but we shouldn't have to. It is especially troublesome because various mobile service providers supply their own browsers on smartphones, leaving open the possibility that theirs might not support either handheld styles or media queries.
What's more, the disuse of handheld stylesheets encourages developers and designers not to use them, increasing the momentum of this particular downward spiral. The mobile web space moves further from the ascribed standards; standards that many have worked so hard to improve and spread.
Some situations call for targeted styles vastly different from each other. Treated badly this could lead to unwieldy use of dimensional media queries, but there are solutions.
The Solution
A relatively easy solution is to import different stylesheets, in whole, depending on the media queries. It's standards compliant and avoids bloating the served files, but unfortunately there are UAs out there that do not select media queries and may ignore any import directive served with one. A default file can be served, but it rather negates the benefit of the technique.
We can handle the issue on the server side, attempting to determine the user agent based on the HTTP header. It's a nice approach in theory, where PHP or similar technologies serves only appropriate content. Unfortunately it isn't reliable, as the user agent string can be readily altered.
The best thing to do, then, is combine techniques. Write forgiving style sheets, use media queries for both device and dimension based differentiation and employ user agent detection on the server. It's a patchwork solution to a patchwork problem.
A lot of people won't bother, but I (and hopefully others) think that it's important to properly employ web standards. These methods allow us to target mobile devices; if the practice spreads it will be noticed by UA vendors and they will move back to standards based handheld style implementation. After all, if handhelds are the future of the internet, then the internet needs to be designed for them.
The Future
Why is it so important to support standards like this? Because we're going to need a solid foundation to build the internet of the future upon.
e-Readers are feasible, increasingly popular devices now. Some of these have, as will more in the future, network connectivity. Knowing this, people will want to use their e-Readers to access the internet. But how should that be handled? Should they follow the current trend and default to screen rendering, or should they use handheld or print styles?
Handheld
Pros
They are handheld devices.
They share the portrait aspect ratio with mobile phones.
Cons
e-Readers (esp. with e-Ink) don't handle multimedia well.
Screen
Pros
e-Readers tend to have pretty good resolution.
Cons
Again, printed v. rich media issue.
e-Readers have relatively small screens.
e-Readers are usually in portrait aspect.
Printed
Pros
e-Readers are designed to simulate printed media.
Print styles are designed for clear reading, like a book or newspaper.
Print styles aren't likely to include multimedia content.
Cons
Traditional print media wouldn't support hyperlinks, whereas e-Readers could.
I'm sure there are other pros and cons for all three of those media types, but I think my point is served; it's going to be a contentious and confusing issue when it gets attention. Some will see it as a new way to serve literature or news, others as another e-commerce vector, countless other opinions will abound. What matters is what becomes most commonplace, which may be a new media type and a matching set of style trends.
In order that that most commonplace approach may be smoothly identified and implemented it must be supported in standards. Only a standards based web, in both the desktop and mobile space, can give us the groundwork for that.
Monday, 17 January 2011
Steampunk: my Philosophy
My post
I've found that different people have very different specific reasons for appreciating Steampunk, but there are certain things that I find quite widespread. I'm going to focus on the relationship between Steampunk and industrialism.
As we can all agree. the genre takes a great deal of inspiration from the nineteenth century in the forms of literature, technology, fashion and other elements. We often talk about taking the technology of the time to its extremes, but in some ways that is exactly what we don't do. It is real history that did that, if one considers that modern electrical power stations run on steam and that today's factories are directly descended from the steam-driven mills of those supposedly halcyon days.
The truth is that the Victorian world (perhaps particularly England and her empire) was in the throes of the Industrial Revolution, which I consider to have reached its height in the nineteenth century (feel free to correct me). The revolution came with billowing smokestacks and pulsating steam cylinders, fine clockwork and precise machining, great dreams and hopes for the future of mankind! Oh yes, these are the things we choose to remember in our genre, the best of the industrial revolution.
But ours is an era of contradiction, as this genre reflects. In the modern world we are subject to, benefactors and victims of, an industrial commercial complex that straddles the globe. People today know luxury and opportunity beyond the dreams of our ancestors, carried onward by matching technology. Still, there is much discontent. We are disenfranchised, the individual a small piece of a larger machine. Few of us are able to fully explore the opportunities that the world claims to offer, we live in the shadow of commercial industry, fed by it even as we are imprisoned.
This too links to the Industrial Revolution. Before those advances in technology, production was achieved largely by means of cottage industry. In that era, individual craftsmanship was the norm. Resources and products were scarce and expensive, without the mass production of later times, and life was hard; yet, in that dog-eat-dog world, every person had the chance for individual accomplishment. Well, more or less.
Steampunk, it seems to me, reaches back into the heart of the Industrial Revolution and tries to undo the damage that was done; we embrace the power of technology and its potential to fulfill our dreams, but we recoil at mass production and the ruination of the craftsman. It is more than an aesthetic, more than literature, it is a deep-seated urge to restore the finest of craftsmanship. This is no easy task, but is served well by the Maker culture and is, it seems to me, becoming more widespread beyond either of these subcultures.
I am well acquainted with the presence of those whose interest is purely out of fashion; there is no wrong in that, such people provide an outlet for the creatives. Similarly, there are those whose interest lies solely in Steampunk literature and art, which may speak to them of who knows what. Still, for those of us who find hope in philosophies like (or unlike) that which I have outlined or those which others have, there is the whole.
Thursday, 11 November 2010
Remembrance day
Now is the time that we are encouraged to remember and honour those who have fought and suffered for our freedoms, or for the follies of our government. It is a valuable time for civilisation; a moment to stop and think so that we may never forget, so that we may hope to learn.
But if we only remember them now, when we are prompted to do so, then we do them a disservice. A lesson given, heard or recited once a year is a lesson not taken to heart.
Since time immemorial people have fought for us, for others, for their kin and most of all for their comrades. The fallen, the injured and the survivors are held up as heroes and so they are, for their will to sacrifice their all for the good of others.
Those left behind to tend the hearths of the nation, to keep society warm, we also must so herald. In the darkness left by the absence of their loved ones, countless millions have fought the odds to ensure that their heroes had a home to which they might return.
Those who refused to fight, out of a sense of honour or respect for life, or for any reason philosophical, often also have performed acts heroic. To stand against the pressure of those who would call them cowards, and the many who served to save and comfort those who fought, they too are heroes.
All of these men and women, their mothers, fathers, sons and daughters, each and every person who has ever had to face any of the multitude of war's horrors, should be remembered and honoured not only now, but at all times. We must never forget their service, their sacrifice or their suffering.
Whenever we goad to conflict, small a great, when anyone shows intolerance for the philosophies and rights of others, it is a slap in the face of someone who has faced horror with honour. When the leaders of nations allow their squabbles to escalate unchecked, they dishonour those who have suffered at the call of those who went before.
Remember the dead and remember the living, but most of all remember the lesson. The world has called enough heroes.
Wednesday, 29 September 2010
In which I Go
I particularly like its clear support for concurrency, as well as the typing system. I feel that I'm learning fast, although interactions on the golang-nuts mailing list help me see that there are still some concepts that I need to learn or brush up on. I think this comes of spending the last few years coding mostly in PHP.
Now the thing about Go is that it lends itself naturally to use on servers, having some nice libraries for common server operations. That being the case I foresee using it in that context, so I set out in search of a database library.
That's one area where the core libraries seem oddly lacking so far, although that may change. However, a Go community member has developed a package called GoMySQL, which I believe will suit me quite well. I've forked the project on GitHub so that I can make any changes I need as they come up, as well as additions.
I'm an Object Oriented programmer, by education. I studied C++ mainly where I became fond of creating classes to represent concepts in my code. Go doesn't have classes, but it is object oriented. It's a departure and an interesting one, in which structs are used where we need data types, but where we need types that offer a clearly defined interface that is exactly what we write, an interface.
It serves to separate the two aspects of a class, its members and methods. Both exist in Go, but they're not so tightly bound. The same methods may apply to structs with different sets of members. A single struct type, with a single set of members, may implement multiple interfaces' methods.
In practical terms this frees design from the tyranny of type hierarchy. A type may be defined that is equally a Reader and a Writer, these being predefined interfaces. It's not a Writer derived from a Reader, or vice versa. It doesn't have both Reader and Writer as parent types. No, it simply is both, as much one as it is the other. It's smooth.
There's a lot more to it, with slices and channels and goroutines. It's all pretty cool stuff, but those are the bits that I felt like mentioning. There may be more as I continue to learn.
I have to say, as well, that I think I probably will work on that game I mentioned. It'll be slow, occasional effort, but Go looks well suited to the server portion of the system, so that's something I intend to do.
Monday, 20 September 2010
Still want to create a game...
I've never found the time to pursue any of them yet, but there's one nagging at my mind. Actually there are two, but one is far too wide and deep to consider without having a fairly sizable team. The one that's really holding my interest right now would be comparatively small, but by no means the work of a weekend.
It's a fairly well formed idea at this point. A multi-player, on-line, real-time-strategy game with a sci-fi setting. The idea would concentrate on cooperative strategy.
It'd have to be divided into a few software components. Most obviously a server and a client, but the server itself I think should be built as a set of small, concurrent servers handling various tasks such as connections and coordination. I believe this would be an excellent application for Go, Google's language, as it has an impressive native approach to multi-threading and inter-process communication.
I see the client having an OpenGL GUI, though I'm curious about using Blender to create models/meshes. Its back-end would probably be best written in C++ or C.
The idea so fires my imagination that I have, in my mind, some reasonably well formed data flow models. I've also drawn a little game art.
Will this get off the ground? Probably not. But it's something that's probably going to hang around, attracting bits of time and effort. I'd need others to join in though, for both development and testing. The trouble there is that while I do have a friend who has just taken up game design as a field of serious study, I could hardly prevail on him to assist. Meanwhile, my pool of coder friends, with free time or otherwise, is relatively small.
And I don't even know OpenGL or Blender.
Sunday, 5 September 2010
The real potential of 3D TV
But I've had a taste of what it can really do. I refer, as I have before, to watching an IMAX film in the science museum that took us to space. One of the aspects that has stuck with me ever since was the reality of the faces on that screen.
I don't care about seeing launch debris race toward me. I am aware that placing my hand in the astronaut's glove was essentially a gimmick. But those faces were important.
When I look at the face of someone standing in front of me I can see the prominence of their nose, the rise of their cheekbones, their brow ridge and socketed eyes. When I looked at the face of an astronaut in that film I could see all of those details.
These are not the shadow plays of old or the paper dolls seen in poorly made modern 3D. These are not dioramic layers or retro magic eye pictures. These are true, deep, rich stereoscopic images.
Enough evangelism, what matters is what this can be used for. I believe that properly produced 3D content could be important for both education and art, two of the most important measures of any culture.
Education begins as soon as we are born, if not sooner. Early in life, once vision has sharpened enough, visual information can be as important as aural and tactile tuition. I recall when my first nephew was younger, watching television programmes and videos made for infants.
Many of these used puppets; these were often brightly coloured with clear, bold shapes and set against a black background. If I remember rightly, from my sisters explanation of her research, this was because young children respond better to visibly real objects (puppets) and greater clarity (contrast, brightness). This was all, of course, on a 2D screen, but consider the advantages offered by 3D.
Those puppets would then appear to really be there, to be tangible objects with real geometry, helping a child's brain to process deeper visual input. They need not use the gimmickry of projecting toward the infant's head, rather they would be better rendered as though on the far side of the screen to complete the illusion. I feel sure that this would have benefit.
Then consider the continued education of growing children. I recall when I was young, being fascinated by images of a kingfisher with its colourful plumage and undeniable grace. How much richer would such an experience and memory be, had I been able to see that bird in its full, three-dimensional form?
By presenting to our children images of such detail we could help them to learn about nature, its structures and wonder. It could have potential for the teaching of geometry, of chemical structures, architecture and more. We could show them great sculptures from around the world.
This leads me to my other point, that of art. If we wish to introduce our children, or ourselves, to great sculpture we must travel for hours to view them. Of course, viewing such works in person will always be the best way, but many people have not the time nor other resources to take these trips. We could at least better see them in our home than today.
But television today relatively seldom shows us paintings. Rather, the medium lends itself to a different sort of art, a modernisation of the traditional theatre play. Players strut and fret their hour upon the stage behind that screen, the camera able to show us nuances of performance that had never been visible to a theatre audience. How much richer might that become, should they appear to stand before us?
Of course the medium would take some time to come to terms with its new aspect. Film makers would have to learn that such depth of view should be as natural an aspect of their work as colour and sound are today. But once this state is reached, what art may be produced!
I must admit that today's detractors rightly point out the primitive implementation of 3D displays today — the need for glasses, the poor image quality, such issues as these — but in time these limitations will be overcome. Once they are, how rich might the medium become.
Friday, 27 August 2010
3D graphics on the web!
The HTML5 canvas element is a fascinating feature of the new standard. With a little knowledge and some further study the element makes it possible to use JavaScript to draw bitmap images directly — and dynamically — in the browser window. It lacks some of the niceties of vector graphics, such as the ability to draw an object once and then make changes without manually re-drawing, but it is a powerful tool.
In order to use the canvas element one must refer to its two-dimensional context. There are lots of code examples around if you want to see how that's done, suffice to say that it is simple. Having a variable to point to that 2D context it is then possible to draw primitives, pre-defined images, gradients and paths, among other uses of the canvas. Paths will sound familiar to any creator of vector graphics but their canvas implementation is more similar to that in image editors such as the GIMP.
That's all fine and dandy and certainly, with clever enough scripting, this 2D context could be used to simulate 3D graphics. Unfortunately it would take script clever indeed and would place a considerable drain on the CPU. I've no doubt that these considerations were among those that motivated a new open standard, WebGL.
This is a remarkable API, based on the OpenGL ES 2.0 specification. Khronos, with members including Opera, Mozilla, Google and Apple, are developing this as an open standard for use with the HTML5 canvas element. It's accessed in the same way as the original 2D context, but what it does is genuinely impressive.
Browsers supporting WebGL (development versions of those from the previously mentioned vendors) use hardware acceleration (the user's video card) to render 3D graphics using the popular OpenGL library.
The results are frankly staggering. Full-3D graphics rendered in real time in the browser, seamlessly integrated into perfectly normal web pages! I can't possibly do it justice in writing, so take a look at the WebGL wiki for instructions and see for yourself! If you don't fancy trying a development version of a browser you could look up videos on YouTube and such.
This is certainly not the sort of 3D that I was talking about in my earlier blog entry, but it's an amazing thing. Using this new context seems to involve quite a learning curve, but the possibilities will surely make it worth the effort for some.