We're past hump week, if such a thing were actually possible in this challenge[^], and we're starting to see the applications come to life. Overall the contestants' apps are coming together and they guys are focusing more on showcasing the Ultrabook and Windows 8 API than merely grinding out the framework code for their application. The contest has gone from "how am I going to get this done" to "how can I make it rock their socks?", and has expanded to more philosophical and design discussions on the nature of the Ultrabook and what it means for user interaction.
Lee is powering ahead. As a reminder he is working on an application that combines social messaging with random pot-luck. His OpenGL-to-DirectX 11 translation engine is working. He has NFC happening (after a little device foreplay - really, too much information) as well as a bunch of other Ultrabook specific support that is truly keeping with the spirit of showing off the Ultrabook hardware and Windows 8 API. Check out his videos if you like a little time-lapse craziness.
George and Suresh at Blue innovations look like they're close to being done with their MoneyBags 2.0. They are, methodically, working through their list of Ultrabook features they wish to support (I think it''s all of them, at last check) and have gone as far as to provide an eBook detailing their progress and their earned wisdom. Grab yourself a copy of A Simple Guide to Ultrabook Development. An important UI issue these lads have discussed is ease of use of the touchscreen. Grab a tablet or iPad and think about how easy it is to reach various parts of the screen. On a 3.5" screen it's all accessible. On a 7" the centre bits take a little wiggling. On a 13" touchscreen laptop there are definitely parts of a screen that are easier to hit than others and an application's design should take this into account. Their use of hidden menus, though, would draw a serious, horizontal-brow'd frown from Jakob Nielson. Don't make your application an adventure game. It should all be obvious.
John and Gavin are also in a great personal space. They are feature complete. Complete with bugs and with optimisations to be done, but complete. They mirror comments made by others that hover is dead. Anyone who's written an app or a website optimised for touch knows that you don't have a mouse or cursor. Unless you insist on stylus based devices, you crazy cat, you. Touchscreens may, in future, have the ability to detect your finger from a centimetre away and provide hover events, but for the moment it's binary: you're touching or you're not.
Sagar loves a little drama and did what any red blooded developer would do when given a pre-release piece of hardware running a pre-release OS with pre-release drivers: he tried upgrading to RTM bits. You can picture how that went. Regardless, their Shufflr video sampler application is fully bean-bag enabled using the inclination and accelerometers. Quick tilt-and-back to flip to the next video. Tilt-and-hold to scan through a video. Very nice.
Andrea is continuing to work on his language trainer. It's coming along, but as I've said in previous posts: I'd like to see something that more fully showcases the Ultrabook. At the very least a discussion on the ins-and-outs of developing touch screen UIs for web applications would be valuable.
Overall, we're close. The Intel Developer Forum is next week so contestants will have a week off to booze, I mean, discuss strategy with peers in informal round-tables, so there will be a break in the regular scheduling.
Initially I thought my vote for the top app was sewn up early. However, as we see how the contestant think, and how they approach the application development process, I'm now torn in 3 different directions. Pushing the boundary hard and far always gets point from me, but sitting down and methodically working through the issues to produce an app that makes sense, rather than on;y being a showcase, shows a deeper commitment to me.
We only have two more weeks for each to finalise their offerings. This will be interesting.
The Ultimate Coder challenge continues and it looks like the contestants are getting down and dirty. To add to the spice I now have in my hot little hands a prototype next-gen Ultrabook loaded with Windows 8 with which to test actual applications. The unit is a pre-production test unit, so it will never actually be on the market, nor is it meant to be a perfectly polished example of the genre. The fact that they provided the sort of power cable you'd find on power tools, and the lid is rubberised so that (a) you can get a good grip on the thing, and (b) it probably bounces when dropped, speaks volumes about the kind of torture to which they are expecting it to be subject. It makes me want to look at them with big, wide, innocent eyes and reassure them that I won't break it. I promise.
I am deliberately not investigating the new Ultrabook features on the demo unit. In fact I'm deliberately not even trying to find out which features it has because I want the contestants, through their apps, to teach me. I want to discover the features, and I want to be amazed. I am, however, re-familiarising myself with windows 8 and The Design Formerly Known As Metro (DFNAM) UI. I'll say outright I'm not a fan of the schizophrenic Desktop/The DFNAM UI split personality.
As a reminder: central to this quest is requirement that contestants "create apps that take full advantage of the performance advances, graphic excellence, touch and sensor technologies of the latest Ultrabook™ computers". This is a competition and while an awesome application that blows me away gets points, only an application that takes full advantage of the unique abilities of an Ultrabook running Windows 8 will win. Showcase the platform, not your application, and prepare to get out of your comfort zone.
As has been a theme, Lee is tromping through with steel shod boots where angels fear to tread. The man is crazy, and I dig that about him. If you are looking to develop Windows 8 applications, follow Lee's blog. He's starting from basics - commenting out windows.h, building (and failing to have success with) static libraries, multi-core development, sensors, DirectX 11 and everything that comes with that.
George and Suresh are continuing with their MoneyBag rewrite. They have progressed to the point where a preview is available, but the download requires registration and no registration email made its way to my inbox. So, as much as I'd love to comment on what they've done hands on, I can't. However, they have continued to provide extensive details on how they are progressing and the challenges they are facing, and have provided a checklist of Ultrabook features they are targeting. Not all Ultrabook features centre around sensors and jet-packs. These guys are focusing on the subtler things such as instant on, touchscreens and Smart Connect.
John at Soma games are discussing what they are using more than how they are supporting Ultrabooks. In particular they posted that they will be using the Unity 3D 4.0 engine - which is an interesting gamble since it hasn't been released yet. While it's great that the Unity 3D 4.0 engine will support the DFNAM UI, I would like to have heard more on how this ties in with their application really showcasing the Ultrabook experience. They demoed touchscreen, DFNAM support means it plays nice with Windows 8, and Unity 3D should push the GPU hard, but I'm hoping there will be some other sensor or power management or notification based component of the game that makes you think "this is a great game on a PC, but it's killer on a Ultrabook".
Sagar have hit another seemingly unnecessary roadblock: ambient light sensor support need the DFNAM. They are also having NFC sensor issues on their Ultrabook, which just continues their run of bad luck. Part of the challenge in this competition is that it's being run on pre-production hardware and so driver support may be immature. I know I ran into a wall trying to get a new touchpad driver, so I'm hoping their contacts at Microsoft and Intel will come through with the goods. At least the accelerometer is working for them.
Andreas is plugging away at his language training app. Since he's chosen to use HTML, issues with building libraries, using native code, and all the fun with sensors is a non-issue. Although, that's a double-edged sword since it limits his ability to really show off what an ultrabook can do.
We'll see what everyone has up there sleeve next week.
The Ultimate Code Challenge[^] continues into its second week. 6 developers, 6 svelte 3rd generation Ultrabooks, 6 apps that will wow and amaze us. In 6 weeks.
Most of you are thinking "and if it were my boss, he'd demand I do it in 3, and the specs would change on day 20". When I was a lad...
Lee[^] continues to work on Love Hearts, a social app for sugar addicts that utilises the Always On Notifications system to send alerts to your co-addicts and have their machine, which they thought was safely asleep, respond to your message by 'pinging' you. At 2am, presumably. Are they talking a polite "pip", or an actual 140dB full sonar ping. I'm sure there's a setting for it somewhere.
At the core, Lee is looking to create an app that showcases the abilities of the Ultrabook and the Windows 8 OS. Pick up the Ultrabook and the game responds. The app is playable using only the touchscreen, and his fundamental philosophy is that the game should be discoverable in an enjoyable way.
I am a little worried, but also grinning a big grin, when he discusses a major issue with Windows 8: a metro style app cannot use OpenGL. So he's going to write his own OpenGL library in DirectX 11. That's so awesome.
George and Suresh[^] continue to discuss MoneyBag, an expense tracking application based on (but a complete rewrite of) their 1.0 version of the same name. The standard challenges of screen resolution and touch vs mouse are discussed, as well as the use of power saving APIs in Windows 8.
I'll be honest with this one: I want to see more use of Ultrabook specific features. I hear rumours of an NFC chip on the units, and what better way to drive adoption of a financial planning application than by offering your users the means to bankrupt themselves by whipping out their Ultrabook from their jeans pocket, tapping it at their local supermarket, and spending themselves broke in a frenzy of Ultrabook NFC tapping madness. I'd do it, simply for the looks on the cashier's face. And then, obviously, I'd need to do some serious self-reflection, probably with the aid of a financial management app, and work out where all the money went.
Shailesh[^] continues to work on his BioIO teaching app. Again, the theme of variable screen resolutions and touch enabled interfaces came up, which is not enough of a differentiator among this group of contestants. I'm hoping they have a killer feature that showcases the Ultrabooks up their sleeves. One niggling comment is that as a dev I read code better than prose, so their screen shots of code at an equivalent of 3px font is a little painful to read. Guys - any chance of posting code as, well, code, instead of images?
Soma games[^] are writing Wind Up football. While I was hoping for a fully immersive experience involving the use of the gyro, accelerometer and touch screen capabilities, combined with your boot and a run-up kick, it turns out they had something far more prosaic, and potentially more sustainable in mind: a touch-screen football game. And it looks awesome. These guys are developing an iPad version in parallel, so have a headstart in terms of game design, graphics and audio, but are already identifying challenges such as variable screen resolution, and, well, a keyboard.
Sagar[^] have entered the second week and hit a brick wall. Metro apps can't use WiDi to stream Metro live tiles to a TV. This is crazy, and invites the inevitable comparison with iOS and AirPlay. They have also hit hurdles trying out the sample code for Ultrabook sensors, and have generously provided info on how to fix them. 5 weeks to go and they've done a reset. This is a pity, but the bigger pity seems to be the Metro/Desktop dichotomy. We all understand that Metro is for phones, tablets, and touch-enabled Ultrabooks, and Desktop for those times you need a desktop, but splitting support for hardware between WinRT and native will make no sense to users. Why would you have NFC support in Desktop apps but not Metro apps? Are you more likely to tap your desktop or your phone at a checkout?
Andreas[^] seems also to have stepped into the minefield that are the Microsoft samples. Once he had the exceptions under control, he found a neat little issue: push notifications will throw an exception if you have no internet connection. Obvious, really, and I understand that samples are merely snippets to get you started, but no exception handling? Guys... In any case, Andreas is on his way.
A se two common themes from the contestants. The first is that the UI for their apps should be easily discoverable. Time and effort is being spent ensuring that the actions you need to take to achieve outcome are obvious. This, to me, signals a serious maturity in Windows application development. Engineers are realising that users don't appreciate their technical excellence: they appreciate an app so easy to use that they forget they are using an app. Hallelujah.
The second is that the samples for Win8 sensor support is a mess, the support for sensors is uneven, and that the library support between Metro and Desktop apps is not consistent. This is a challenge. An unnecessary challenge, in my opinion. It does, however, make my life as a judge far easier because the harder the challenge the more the field is split.
A small disclaimer: in this post I use the term "Metro" to refer to the name of the Design Language Formerly Known As Metro simply because that's what the contestants are using. It has another name that I keep forgetting, so for now, when you see the now-defunct term "Metro", simply replace it with "The Design Language Formerly Known As Metro" and all will become clear.
There have been many arguments on whether code should be commented. Here's my experience.
Comments fall into two buckets: Object and method decorations - those that explain what a file, object or class does - and in-code explanatory comments that appear inside methods or blocks of code to add explanations, notes, or to explain the non-intuitive.
Anyone who says that there is no place for comments inside methods is, to me, misguided at best. Code is not a literary work of fiction open to various interpretations. It's a precise series of instructions, and sparing, sensible, well-placed notes on what's going on inside a method can prevent disasters.
There are many, many, many developers and proscribers of dogma that insist that decorative comments are also unnecessary. The standard argument is that names should be clear, descriptive, unambiguous, and as long as necessary.
If we all spoke the same language, had the same cultural background, same experiences, same literary ability, and all wrote code at exactly the same time, using the same, precise naming conventions, then yes, good naming will solve most ills and decorative comments are not that essential.
However, we don't work in this environment and it's extremely short sited, and costly in the long run, to think we do.
A term used in one context may mean something different in another. A trivial example is "Create" which could mean create a new object in memory, or store an existing object in a row in a database.
A term used in one culture may mean something different or, in fact, the opposite in another. To "table" something in North America means "to postpone for consideration". In the UK, Australia and the rest of the English speaking world "to table" means to begin consideration of the topic.
While it's straightforward to use names that are more descriptive it's important to understand that ambiguity is often difficult for a single developer to spot. They know what they mean, but it's only after other developers look at their code that it becomes apparent that other developers may not. Do not fall into the trap of assuming everyone understands what you mean.
One solution is to mandate that names be fully descriptive: CacheObject, UploadToCloudStorage, DiscussIssue. This helps a little, but very soon you hit the point where providing an unambiguous descriptive name stretches the limits of acceptable name lengths. Steve McConnell writes that method names should be between 9 and 15 characters. Good luck.
Still, this doesn't help. No matter how well you name something, how consistent you try to be, how dire your threats are to other devs, you'll always have situations where you just don't know, with absolute certainty, what a method does. With no comments the developer needs to go and read the method to understand what's happening. This is a monumental waste of time, and worse: it's frought with peril when code is read but the intent not understood.
Another issue is parameters. While the same arguments for tight and descriptive method names should be applied to parameters, it's almost impossible to encode in a parameter name things such as restrictions on acceptable input values or notes on special value handling. Comments on parameters allow you to understand the results of suppling null, 0 or empty values, and to understand the limits of what you can supply.
My approach is you should be very, very careful with object and method names, and strive to be descriptive and unambiguous and have as your goal a 95% clarity on naming. That is, 95% of the time a developer reads a method name, that name is clear and unambiguous. However, the list of ambiguous names - that 5% - will vary per developer. That list of ambiguous names may even vary over time for yourself. A simple, clear, well-written, and up-to-date comment will solve this ambiguity.
The "up-to-date" specifier raises the issue of drift. The purpose of a given method may drift slightly from its original intent. The comment attached to that method may then be slightly (or seriously) out of sync with the intent. So too may the method name. To use the argument that comments are useless, and at worst, dangerous because they may not represent what the method does can, and should be applied to method naming as well. When a developer updates a method is it easier for them to make a note of any provisos in the method comment, or is it easier for them to rename the method, and hence the object's API? The method name and the comment should both be kept up to date. Developers get tired and cut corners though.
The way I approach software development is to assume the worst. I assume the inputs to my methods will be bogus. I assume methods will return null. I assume the database will explode in a searing ball of plasma when I run a query. I also assume that my wetware will also have issues and that, at one time or another there will be confusion.
The means that all methods and parameters are commented. This ads approximately a minute of development time to each method. It also adds a small amount of time each time a method is changed to scan the comment and ensure it's consistent. It also means we have a ton of comments that, 95% of the time, add no value. However, since the set of methods that raise ambiguity or clarification issues is non-fixed, it's not practical to simply comment 5% of the code.
While it's tempting to say "just comment the methods that need it", this leads to a slippery slope that we've seen in practice again and again. The test of "what needs it" is carried out by the coder, who almost by definition finds their code clear and unambiguous. One by one "obvious" methods are created without comments and soon we have devs interupting their work and that of the author to discuss what's happening.
The application of under a minute of effort saves 5 minutes of conversation and the inherent costs involved in task switching productive developers.
Comments aren't things that hang around code like bad groupies. They are code, and when the code is updated, so too must the comment.
The Intel Ultimate Code: Ultrabook challenge[^] is an interesting experiment. On the surface it’s a coding challenge: Six developers compete for six weeks to create apps that take full advantage of the performance advances, graphic excellence, touch and sensor technologies of the latest Ultrabook computers. Scratch a little deeper and you realise that this is a 1 part coding and 5 parts hair-tearing game of strategy combined with your worst mid-term practical, ever.
Six Developers (well, eight actually - you can see the rules are already being tested at this early stage) get 6 weeks to develop the ultimate app for the Ultrabook that makes use of Windows 8, touchscreen capabilities, sensors such as gyroscope, GPS and NFC (to name a few), and the raw power of a 3rd gen Ivy Bridge i7 CPU.
For the next 6 weeks I'll be posting updates on the progress of the challengers. These are seasoned developers. They have been around the block and have a full shed of tools and tricks at their disposal. They are not to be trifled with. I am expecting, and maybe hoping, the veneer of gentile competitiveness to fall away quickly and settle down to a nice exciting game of psych.
Lee[^], for example already has an app-in-a-box application that will enable him to write his apps in Basic and target 7 different platforms. He’s using Basic. To write the ultimate app on the ultimate notebook in front of millions of developers. You can see the sorts of mind games that have already started.
George and Suresh[^] have reportedly tried out over 30 designs concepts and more than 200 assets to arrive at their final design. In less than 3 days. They also already have mockups of their final app and will be building on an existing app. In this day and age merely changing the font is enough to warrant a major release, so I’m going to be watching these guys closely. And it should be noted that any use of Comic Sans in an application leads to immediate disqualification.
Shailesh[^] from clemsoftware will be creating an Ultrabook tuned version of their BioIQ picture puzzle game. Basically: label the parts of the organisms and you win. I’m guessing touch will be a large part of the ultrabookification of this app, but what I’d really like to see is something far more immersive such as a modern day version of the children's “Doctor” game. Either through touch, or by tilting and moving the entire ultrabook you control a surgeon's knife and perform something simple like a coronary bypass. I breezed over the specs of the ultrabooks sent to the devs, but I’m sure there’s something that would add a little je ne sais quoi to it all. An electrified touchpad or the NFC chip wiping your credit cards in a “simulated” malpractice suit would add a little spice, no?
John[^] and Gavin from Soma games (I think this makes it 8+ devs, right?) are creating an app called wind up football that takes advantage of the touchscreen and accelerometer. I will be satisfied with nothing less than an app that requires you to actually kick the Ultrabook in the same way virtual golf courses have you hit a golf ball into a sheet. The touch screen can measure the location and, potentially, vector of your foot, the accelerometer can then calculate the projected path, and the gyroscope would be used to measure rotation. Their challenge will be accurately simulating the aerodynamics of a flying, spinning Ultrabook, but I assume that’s why they also mentioned the new CPUs as being integral to their app. Nice one, boys. I’m definitely looking forward to this one.
Sagar[^] and his crew made much mention of the trials of actually getting their hands on their Ultrabook, which is actually a step further than us judges have managed to get because we’re evidently embargoed from getting our greasy, cynical paws on the shiny new ‘books until the challengers have completed their penultimate post. Sagar did mention in passing that the judges pics were way cooler than the challenger’s pics so he gets 2 points this week. However, I do need to subtract 2 points for dropping the “e” in his product’s name. Ever since auto-correct was invented spelling has gone to hell in a hand-bascet.
The short version is we have a new article submission wizard (and updated systems) that provides
- An all new, single page article editor.
- An auto-save facility in case of crashes
- The ability for members to edit "edited" articles safely. No more needing to send in updates manually.
- Simplified references to uploaded files.
- A new "Alternative article" option that allows you to create alternate versions of existing articles
- An update for Tips n' Tricks so that they now use the standard article UI
- You can now upload images and downloads for blog and tip articles.
- The ability to easily switch article types (Make an article a tip, promote a technical blog to full article, etc)
The longer version:
About 6 months ago we finally had the time to revamp the aging submission wizard. I wanted a single page editor that allowed in-page (ie Ajax) file and that looked very much like what the final article would look like. The idea is that it would feel like you were editing the article in-place. Click on the title to edit it, upload a file and add the file to the content with a single click etc. And, of course, auto-save with a simple recovery model for those bad times.
I also wanted to address the need to allow our authors more access to their articles. Currently what we do is we pick the top articles and edit them. This editing corrects formatting, spelling, cleans the downloads and generally ensures that the article conforms to our standards. However, once an article is edited by an editor it is inviolate: it can no longer be updated online by the original author.
The reason for this is that, after spending so much time fixing articles, we were getting a little frustrated when members would go an re-edit the article's we edited and re-introduce all the errors we had fixed. This is understandable because they would often simply take the copy of article they had originally written, make corrections to it, then copy and paste it over whatever we had done. So we put an ednd to that for our own sanity and made a pact with ourselves (and with you) that we would be as fast as possible in posting updates you sent in.
However, this punishes those who are good authors for the sake of protecting the few that are bad, so we've come up with a compromise, and also a solution to a subtle problem.
Previously when you posted an article using the wizard, the article would be placed in a Pending queue and would be reviewed by other members who would then approve, disapprove, and/or comment on the article. After approval the article became public and everyone was happy. Except that the author could now edit their new article, upload a bunch of inappropriate material, and have it available immediately. The solution was to modify our system so that all edits of articles create a new pending version of the article. After editing, the old version will still be seen by most members, but moderators will be able to see (and approve) the new version. Once approved the new version replaces the old version and goes live.
In doing this we had to tackle a few issues with files. We choose not to store files as database BLOBs, but as system files, so where do we store your upload files while you're editing? When you start the submission wizard you haven't chosen a section, yet you can upload files. When editing an existing article you may need to upload new versions of files (updated zips or images) but we need to ensure the old version of those files and images are still available for the current article.
We ended up introducing a "Working" directory for your new uploads in order to separate out the old and the new, but this then made life difficult for those looking to reference files in their article's HTML. Previously we had the concept of a "Basename" for an article, which was effectively the name of the article's directory, and which author's used to reference an uploaded file (eg src="basename/myfile.zip"). We've abandoned that since it causes problems with name uniqueness, and in fact abandoned the whole concept of asking members to worry about directories. Now you simply reference an uploaded file by its filename, and we make sure we track things like which file (old or new) you're talking about, as well as ensuring we adjust the references in your articles during the various stages (composing to pending to available).
We've also introduced the concept of Alterative Articles. There are many, many articles that are no longer being maintained and this is a first step to allow other members to take over abandoned articles, or to simply provide different implementations such as a different language.
To provide a symmetric article experience we've now upgraded the Tips n Tricks articles to be displayed in the same manner as traditional articles (as well as their alternatives), and now make it very simple to convert a tip to a standard article, or to any other article type. No more complaint about short articles or long tips. We can quickly recategorise as needed.
This also brings a nice benefit: you can now upload images and zips to your blog and tips articles.
With regards to moving tips to the new UI - you might notice something a little weird with your rep. We moved all the comments that were associated with tips into their own separate forum for each tip instead of having the confusing comments-per-tip-plus-bonus-forum-at-the-bottom.
This release should be conidered a Beta release, so please send in all feedback and bug reports to the Bugs and Suggestions forum.
As far as we know the kinks are gone, but we have seen a couple of issues from bugs in our old system that only manifested once we moved to the new system. It's amazing how these bugs hibernate - like cicadas.
What is the URL of the article? I'll take a look and sort out whatever the issue is.
I fixed up the links and it's all good now, though I think I may have inadvertently published a version of your article you were still working on. If you wish to rollback, go to the Revisions tab on your article, choose the version you wish to revert back to, and hit revert.