-
"In this piece, each of the departments involved in making a videogame are examined and accused of one particular vice. In making these assessments, the assumption behind each is that the purpose of the videogames industry is to make games that players want to play, and not to make the games that developers want to play." It is good, and I'm looking forward to the second part.
-
"…as developers, we need to deal more honestly with the disparity between our reach and our grasp – which is to say, what we tell ourselves our games are about, versus what they are actually about. History will see this decade as the period when games struggled with their destiny in this way." 2K Marin's JP LeBreton with a smart, insightful take on the road ahead for games design, and the many positive steps being taken along it (and: a decent commentary on the "shooting people" issue).
-
"With limited influence, unlimited hands in the pie, a low barrier to critique, and the perception of triviality, frontend engineers are the janitors of software development. Rather than cleaning up trash, the boulder they toil beneath is skew: the distance between team member's conceptions of a project." This really feels very familiar: it's the most under-appreciated art in the stack of software development, and the one that takes the brunt of the crap.
-
"Best of all, for impatient gamers the developer plans to conceal load screens with a mini-game where players can connect a USB keyboard and write an undergraduate thesis on the illustrations of Gustave Dore." Seriously, this already sounds much better than the Redwood Shores version…
-
Farbs quit 2K Australia. This is his resignation note. It's fun, and not in any way mean.
-
"Red dot fever enforces a precision into your design that the rest must meet to feel coherent. There’s no room for the hereish, nowish, thenish and soonish. The ‘good enough’." Dingdingding. +5 points to Taylor, as usual. Place, not location.
-
"TinkerKit is an Arduino-compatible physical computing prototyping toolkit aimed at design professionals. The interest in physical computing as an area in development within the creative industries has been increasing rapidly. In response to this Tinker.it! is developing the TinkerKit to introduce fast iterative physical computing methodologies to newcomers, and particularly design professionals." Standardised modules, standardised connectors, Arduino-compatible. I remember Massimo showing me his keyboard-emulating board ages ago. Nice to see Tinker productising the platform, too.
-
"The buttons are designed to look very similar to basic HTML input buttons. But they can handle multiple interactions with one basic design. The buttons we’re using are imageless, and they’re created entirely using HTML and CSS, plus some JavaScript to manage the behavior." Dark, dark voodoo, but very impressive – and excellently explained by Doug Bowman. It's nice to see Doug blogging again.
-
"If 2009 is going to see the emergence of high-quality browser-based games, then 2009 is going to be the year of Unity. It has: lots of powerful features; iPhone support; Wii publishing; a developing community; quality developers using it; and an upcoming upcoming PC version. In short, it is about to make a major splash. I feel compelled to jump in with it — the indie license is cheaper than the Flash IDE."
-
"bash completion support for core Git." Ooh. This looks really, really nice.
COI Browser Standards Draft – my response
10 September 2008
The COI have recently published a draft of their browser guidelines for anyone developing a public sector website.
Frankly, I’m very unimpressed; they’re dangerous, vague in certain areas and over-specific in others, and promote some terrible ideas. I’d urge any designer or developer with an interest in this area to download the document and read it – it’s really not very long – and then leave feedback on the document with the COI through the appropriate form. The public have been asked for responses, and we have the scope to respond; if you feel as strongly about what’s in the document as I do, I hope that you will.
My own response follows.
As a web development professional, I’m very unimpressed with this consultation document, and would go as far as to suggest that some elements of it are actively harmful.
I appreciate the attempt to codify the need for effective browser-compatibility for all public sector websites. That said, the manner in which the document suggests which browsers to test is very poor.
All browsers are different, even though the HTML and XHTML specs remain the same. The purpose of browser-testing is not to ensure that sites look identical in all browsers; the purpose is to ensure that the site is usable in all browsers.
As such, lists of browsers to be tested in are dangerous; the best we can aspire to is to write good, valid code that is functional in all browsers, and priortise appearance for the most modern browsers.
I take exception to the notion that the browsers to be tested on are those which have >2% share of visits on a website. 2% of hits on a very popular public-sector website might account for a sizeable proportion of users, and to exclude them (especially if the lack of testing in their browsers leads to impared functionality) could well contravene the Disabilities Discrimination Act. Also, note that these statistics are not necessarily accurate, and may contain spoofed or inaccurate user data.
Going beyond the 2% hurdle, it would not be feasible to test in all browsers. The best solution is probably a form of graded browser support, much as Yahoo recommends, which itself is reviewed and updated over time, and which guarantees a minimum functionality in certain families of browsers, full support in others, and makes it clear which browsers simply are not supported. Browsers do not cost money; they are not complex tools to install, and developers should not be limited simply because a certain percentage of users on their website continue to user Internet Explorer 5.
Browser support should not be a series of boxes to check off, and it should not be specified retroactively based upon current users; it should be based upon accurate specifications and usage patterns, to ensure that public sector websites – many of which already have high production costs – are sustainable, maintainable, and functional for years to come.
As such, this preliminary draft has a long way to go before it accurately represents the state of web usage, not to mention web development, in 2008.