Fishpool

To content | To menu | To search

Tag - design

Entries feed - Comments feed

Thursday 9 May 2013

HTC One - an unreview, or what could be done better?

Finland is a funny market. Home of Nokia, most interesting devices take a while to actually become available here. Three years ago, I got my Nexus One by help from a colleague based in UK. It served me well - while it had always been pretty short on memory and for a long time had not been too impressive in terms of speed, it had a nice form factor and, even by today's standards, a fairly good display. However, I had been planning to swap to something more up to date for a while.

The Nexus 4, however, still isn't available here. Sure, at times a local retailer might have a few units with a pretty unattractive price, but the value proposition Google gave for the device is unreachable, since they will not deliver it from Germany, France, or UK to Finland. So much for the unified trade region of the European Union..

13050001_1 So, when I first heard of the HTC One, I had not picked up anything as a new device. I had considered a Galaxy S III, but I can not warm up to the imitation-chrome-rimmed plastic design Samsung is so fond of. In sharp contrast to that massive sales hit of the Android world (behind only the iPhone in sales figures), HTC One is a gorgeous design item. Enough has been written about its surface features, I see no point adding to that conversation. To my eye, HTC One wins the physical aesthetics crown among current phones, with the iPhone 5 and Nokia's Lumia 720 coming behind it. Each represents a very different philosophy and executes the details well. Anyway, I'm more of an Android guy, so even if One wasn't so gorgeous, I would not pick an iPhone or Lumia for myself.

But Finland isn't among the first markets for HTC either - heck, often it isn't an early market even for Nokia. In addition, One has suffered several delays, just barely making it to some markets ahead of the Samsung Galaxy S4, which must be its worst rival. So, especially since I managed to crack the Nexus One's screen to an unusable state, I had to resort to foreign help again - always a bit of a gamble with even with unlocked phones, due to the network differences. Since I couldn't locate a device in Germany, it was time to look what UK could deliver. And deliver it did - through Ebay, I received an untouched, still-in-retail-wraps HTC One last Friday.

I have to say it's just as beautiful in real life as it was in pictures. The finish is exquisite, with the aluminum, glass and polycarbonate seamlessly fused together. I would have happily traded 10 grams more mass and a millimeter in thickness for a more powerful battery, which I'm certain is the weakest part of the device, but it's not difficult to come up with a strategy that will take the device through my regular working day. As most reviews have concluded, it's at the top of Android models, if not of all smartphones.

But what of the un-review? Here are the things HTC has failed to do a good job with, all in the software installed on the device, as noted over one week of use. Where I've figured out a workaround, that's noted, too.

  • The Power Saver - yes, it has one built in. However, the way it's implemented (as an always-there checkbox at the top of the Notifications panel), it obstructs Android 4.1 from presenting the expanding notifications (which are present only for the topmost item). Those notifications are very useful. So, long-tap on the power saver option until an App Info pop-up appears. Through that, you can kill the Power Saver to recover the notification menu. For power saving itself, I use Llama profiles and a few events I've come up with over time.
  • The Calendar - several dealbreaker presentation problems, such as no weekday info in the daily view, no event labels in the weekly and monthly views (despite plentiful resolution to display small type on the Full HD 4.7" screen) and terribly confusing multi-calendar display options. I replaced it with Google's own Calendar app, hiding the built-in tool. They'll show the same calendars and this swap in no way prevents the lock screen and BlinkFeed from continuing to show calendar entries.
  • The keyboard's auto-complete and auto-correct is really irritating, including that hitting space will complete words but not insert the space. Replaced with SwiftKey, which is a far more competent solution anyway - but I might not have done it, had the keyboard been just that tiny little bit more finished.
  • The Share menu in HTC's own apps, including the browser. Limited to showing only four sharing options, among which HTC's own service and the not-so-great Mail app, all of the tools I use to share content (most notably GMail and Buffer) require extra taps. Chrome does not suffer from the same issue, though, so for browsing, this is easily bypassed. Too bad, because the HTC-customized stock browser is otherwise quite competent, slightly faster, and supports Flash for the few situations where that still is valuable.
  • That Mail app. Sure, it will connect to various mail servers including Exchange and private IMAP servers, but it's not nearly as polished as the GMail app, and all my mail accounts are backed by GMail anyway. This would not be a big deal, except for..
  • The lock screen is able to show weather, upcoming calendar entries, incoming SMS messages and the latest mail headlines - except, it will show the latter from the Mail app only, not from GMail. D'oh. Naturally, some might prefer to not show that potentially sensitive data on the lock screen, but I'd prefer the convenience, if it worked.

While overall I still prefer stock Android to these manufacturer customizations, HTC has improved on a couple of points. BlinkFeed is a nice presentation of news, Facebook and Twitter streams without leading to any undesirable duplication of work so common in these aggregation apps, the People browser that replaces both Android's Contacts app and the stock dialer is pretty good, though it takes some getting used to, and the camera application is a good use of the unique capabilities of the device. Of the major flaws, only the Mail/lock screen issue is something I have not found a workaround for, and it's a stretch to call that issue major. Nonetheless, I hope and expect HTC to deliver an update (perhaps along with Android 4.2) that would address these issues, many of which have been already noted by others, too.

Oh, and the camera? Its 4MP "UltraPixel" direction certainly sets the device apart from the competition. I have not done comprehensive side-by-side tests of it, but it does have good low-light performance (especially considering others, including the Lumia 920, use much longer exposure times and thus suffer from more motion blur, even if their image stabilization were able to eliminate camera shake). Perhaps the color balance could be slightly better. As for the resolution, it's certainly enough for online use, though won't leave much room for crops. Considering no mobile camera apart from the already-extinct PureView 808 can compete with a zoom-enabled pocket camera, let along a DSLR, I think the camera performs where most consumers would need it to. I hope HTC's gamble will pay off, and those same consumers won't be misled by the megapixel wars.

The other stand-out feature, unmatched sound output certainly stands out as well. This is the first mobile device capable of putting out a decent audio stream that I've tried. I doubt music will ever truly sound good at this scale, but at least its recognizable even from a distance. Most importantly, voice output comes clear and loud, so this is by far the best speakerphone ever made. If there's anything I can fault it with, it's this - even the lowest volume setting is sufficiently loud to carry over in a quiet room in a way that might bother other people nearby. I'd like one more setting below it, but headphones solve this with minimal inconvenience.

Tuesday 5 February 2013

Arbitrage as a game mechanic

Reading this rather amazing story about cross-border arbitrage, I could not help but think about how it applies to game design.

Here's how the arbitrage math adds up. The ferry costs approximately $275 round trip, and gas is about $8 a gallon in Sweden, which, if we assume our car gets around 30 miles per gallon, gives us $435 in expenses. Throw in food, lodging, and other miscellaneous costs, and the total should come in around $600 or so. Remember, diapers costs more than twice as much in Lithuania as they do in Norway, so we only need to buy that much to break even.

If in the real world it's possible to entice enough entrepreneurial activity from a neighboring country to make the supermarkets of south Norway run out of diapers, imagine how powerful arbitrage opportunities are for game design. It can do everything:

  • Increase play frequency, as you need to come often to exploit recurring opportunities
  • Drive explorative gameplay, as more and more players search for new kinds of arbitrage
  • Incent specialization, because to exploit arbitrage, you need to focus on a particular activity
  • Drive expected lifetime up, as leaving the game means leaving value on the table
  • Drive lifetime value up, because in a free-to-play game, longer play time means more opportunities to buy
  • Drive virality up, because players have incentive to find both supply and demand for their particular arbitrage skill

Many of these factors apply even to a single-player game that simulates market activites. Look no further than the classics of market games, David Braben's Elite (1984) (or Star Trader, which preceded it by a cool 10 years). However, the forces really come to forefront when applied to a social game where the arbitrages don't need even need to be programmed in, as long as the design doesn't eliminate their possibility. Players will probably discover them.

That doesn't mean it's trivial to fully exploit that capability, though. For example, I don't think we ever really explored the arbitrage mechanics fully in Habbo Hotel, even though the system is full of player to player trading, rare items, well-hidden nooks and crannies, and whatnot. The most important feature missing in Habbo Hotel is rich support for specialization. RPG style games bring specialization through character classes and skills, resource management games through directing players to invest their earned resources in a particular type of activity, and so forth. The game mechanic should reward specializing, by making it possible for a player highly capable in a particular section of the gameplay to trade that capability with others for the skills or resources provided by another type of specialization. Don't reward being a generalist, or allow maximizing all stats.

Tuesday 21 June 2011

On software and design, vocabularies and processes

Having recently witnessed the powerful effect establishing a robust vocabulary has on the process of design, and seeing today the announcement of the oft-delayed Nokia N9 finally hit TechMeme front page, I again thought about the common misconceptions of creating software products. It's been a while since I posted anything here, and this is as good a time as any to do a basics refresher.

A typical axis of argument sets software engineering somewhere between manufacturing and design. I, among many others, have for years argued that the relationship of software to physical manufacturing almost non-existent. This is because while the development process for a new physical product, like any involving new creation, starts with a design phase, the creation of a specification (typically in the hundreds of pages) is where the manufacturing really only begins. The job of the spec is to outline how to make the fully-designed product in volume. In comparison, by the time a software product is fully-designed and ready to start volume production, there is no work left - computers can copy the final bits forever without a spec. There's more to that argument, but that's the short version. Creating software is the design part of a product development process.

So, goes the line of thinking, if software is design, then it must be right to always begin a software project from zero. After all, all designs start from a blank sheet of paper, right? At least, all visual designs do... No good comes from drawing on top of something else.

If this truly was the case, what do you think they teach in art schools, architecture departments, and so on? Technique? For sure, but if that was all there was, we'd still be in the artesan phase of creation. History? Yes, but not only that. An important part of the history and theory of design is establishing lineage, schools of thought, and vocabularies which can serve as a reference for things to come. All truly new, truly great things build on prior art, and not just on the surface, but by having been deeply affected by the learning collected while creating all which came before them.

Not having actually studied art, I have only a vague idea of how complex these vocabularies are, and this is an area where a Google search isn't going to be helpful, as it only brings up the glossaries of a few dozen to at most a hundred basic terms of any design profession. This is not even the beginning for a real vocabulary, since those describe to a great detail the relationships of the concepts, ways of using them together, examples of prior use, and so on. However, even from this rather precarious position, I will hazard a statement which might offend some:

Software design, in terms of the vocabulary required for state of the art, is more complex than any other field of design by an order of magnitude or more. The practical implication of this is that no new software of value can be created from a "blank sheet of paper".

This will require some explanation. Let's tackle that magnitude thing first.

Any complete software system, such as that running within the smart phone in your pocket, measures in the tens, if not hundreds of millions of lines of code. LOC is not a great measurement of software complexity, but there you have it. In terms of other, more vocabulary related measurements, the same system will consist of hundreds of thousands of classes, function points, API calls, or other externally-referable items. Their relationships and dependencies to each other typically grow super-linearly, or faster than the total number of items.

By comparison, the most complex designs in any other field are dwarfed. Yes, a modern fighter jet may have design specs of hundreds of thousands of pages, and individual parts where the specs for the part only are as complex as any you've seen. Yes, a cruise ship, when accounting for all the mechanical, logistic and customer facing functions together may be of similar complexity. And yes, a skyscraper design blueprints are of immense complexity, where no one person really can understand all of it. However, a huge part of these specs, too, is software! Counting software out of those designs, a completely different picture emerges.

None of these designs would be possible without reusing prior work, components, designs, mechanisms and customs created for their predecessors. Such is the case for software, too. The components of software design are the immense collections of libraries and subsystems already tested in the field by other software products. Why, then, do we so often approach software product development as if we could start from scratch?

Why was it that the N9 reminded me of this? Well, if stories and personal experiences are to be trusted, it seems that during the process of creating it, Nokia appears to have "started over" at least two or three times. And that just during the creation of one product.. As a result, it's completely different, both from a user as well as a developer standpoint to the four devices which preceded it in the same product line, and two (three?) years late from it original schedule. Of course, they did not scratch everything every time, otherwise it would never have finished at all. But this, and Nokia's recent history, should serve as a powerful lesson to us all: ignoring what has already been created, building from a blank sheet instead, is a recipe for delay and financial disaster.

Software is design. Design needs robust vocabulary and the processes to use them well, if it is to create something successful.

Tuesday 8 December 2009

The balance of great products and rapid evolution

I wanted to link to Andrew Chen's recent article, Does every startup need a Steve Jobs, because it's a useful discussion about the differences between technical feasibility, design-led desirability, and business viability, a triplet productized by IDEO, and one that we also identified a decade ago at Razorfish (wow, it's really a decade ago!). As for the question in the title - no, I don't think that's the only way to create greatness, though clearly if you have Steve at your disposal, you could do worse than have him run everything. :)

Seriously though, at least in this consumer-targeted software business that I'm familiar with, it's crucially important to have those three principles well represented at every level of the business. Sure, it's possible to create a successful business with just two or perhaps even just one of those viewpoints, especially if you can get away with copying someone else but just doing it with better economics. However, to create something new and be successful, it'd be a mistake to ignore business, technology or design. Sadly, of the three, design is the one most commonly ignored. According to this interview of Ken Auletta of his new book, even Google ignores it, Marissa Mayer notwithstanding.

Anyway, what I'm particularly interested about is how can you marry great design with incremental, rapid iterations on the market. I'm pretty sure I've understood how to iterate out in the open with regards to technical work, and relatively comfortable with iteration regarding business aspects. I've yet to come up with a really convincing argument for iteration and design on a very granular basis - well, I can convince myself, but I'm having less success convincing designers. :) If anyone cares to share their secrets, I'd love to hear more.