---

Yesterday, Twitter announced #Music, their music discovery platform. It looks beautiful, but conceptually it’s a bit of a mess. (The Verge have a good #Music hands-on, but the idea is that #Music crawls Twitter for links to songs in order to calculate which artists and tracks are ‘trending’ on the network, then allows you to play through those tracks. It also allows you to view which musicians other Twitter users follow, and which tracks those Twitter users have played recently).

Twitter, the company, have a very real issue, which is that they’re bounded by the limitations of Twitter, the service. Twitter is a social network defined by resource scarcity: users are provided with 140 characters at a time, and it’s working out how to communicate within those constraints that makes the service compelling. Because the limitations of Twitter are so clearly defined and so fundamental to how the service is used, it’s difficult for Twitter HQ to mess with the core Twitter experience.

Twitter HQ have been moving in two directions recently. First, they’ve been trying to slowly shift our understanding of what a “tweet” means, by rolling out “expanded tweets” and “cards”, which allow some publishers to package rich media and long article summaries into tweets. In general, though, users still expect the core Twitter experience to revolve around 140 character bursts of content: it’s very difficult for Twitter HQ to innovate much around that limitation.

The other direction Twitter HQ are pushing is in launching “sister apps” that augment the Twitter experience without actually changing how Twitter works at its core. Instead of rolling innovative looping video sharing into Twitter directly, for example, Twitter HQ launched Vine. Now we have #Music.

The core issue with #Music is that it builds a music discovery layer on top of Twitter, which is not itself a music discovery service. There’s a kind of cognitive dissonance at play in #Music, which makes the service at times difficult to really understand. For example, when you click on an artist in #Music, you’re presented with a standard Twitter “Follow” button, which conflates “Liking a musician and wanting to hear more of their music” with “Wanting to subscribe to their stream of 140 character updates”. Similarly, all Twitter users, whether they’ve signed up for #Music or not, now have a new profile page at https://music.twitter.com/[username], which lists all the (verified) musicians they follow on Twitter. This makes some degree of sense, but not a great deal of it. After all, most of us don’t follow Twitter users to explicitly express our musical taste, and following a musician on Twitter is not necessarily an endorsement of the music they produce. Does wanting to follow the bizarre 140 character musings of Kanye West mean you’re necessarily a fan of Kayne West’s music? To #Music, yes.

In a similar vein, we don’t necessarily follow other users on Twitter because we share their musical taste. At this stage, though, there’s no way to stop seeing recommendations from a user you follow on #Music unless you unfollow them on Twitter, because the two services share the same underlying network. Twitter now provide two distinct reasons to follow users: to follow their updates (on Twitter), and to track their musical taste (on #Music). The “follow” action has been overloaded.

Because Twitter is not, at its core, a music discovery service, many of #Music’s features are necessarily clunky. The #nowplaying feature of #Music lets you track what your friends are listening to, but in order for the track you’re listening to to appear on #nowplaying, you must explicitly post a link to that song on Twitter. That’s great for Twitter HQ, because anything that encourages you to share more on Twitter is a win, but is it elegant? Platforms like Rdio and Spotify are already able to accurately assess what your friends are “#nowplaying”, because they can actually track what your friends are listening to… because that’s what they’re built to do. Twitter HQ’s #nowplaying solution is essentially a hack on top of Twitter, and an inelegant one at that, because it encourages users to junk up their Twitter streams with links to tracks on iTunes, Rdio, and Spotify. Again, it’s very clear why Twitter HQ would want to encourage this, but that doesn’t mean it’s a net win for users. Nor is it clear why #nowplaying should even exist: services like Rdio and Spotify already do the same thing much better.

What it comes down to is this: the only way for many users to experience #Music properly is to change how they use Twitter. If the only way to tweak your recommendations on #Music is to start following musicians or users with great musical taste, Twitter HQ have now complicated the act of “following”, and if the only way to share your musical taste on #Music is to tweet links to songs, Twitter HQ have now complicated the act of “tweeting”. Twitter HQ have built a music-sharing and artist-discovery service on top of a service for sharing short bursts of information. There’s a strange misalignment between the two services.

Ultimately, Twitter HQ are stuck between a rock and a hard place. It’s fairly clear they’re pretty sick of Twitter as a conduit for 140 character group text messages. 140 characters of text isn’t sexy. Music and videos are sexy, but Twitter HQ can’t revamp Twitter to make it sexier, because at least a sizeable minority of Twitter users are wedded to Twitter’s unsexy limitations (and, in fact, paradoxically find those limitations very attractive). In order to explore the hot and lucrative multimedia stuff, Twitter HQ must work out a way to build on top of Twitter while at the same time ensuring that the core Twitter experience remains unsullied. Twitter’s #Music experiment shows just how difficult that’s going to be.

---

or

“Why The Best Symbol is the One That Gets the Job Done”

 

For at least the better part of a decade, tech bloggers and designers have batted blog posts back and forth discussing the necessity of replacing the old floppy disk “save” icon with something more “timeless”. Basically, the issue boils down to the fact that (almost) no computing devices use floppy disks as storage devices anymore, which purportedly makes the continued use of the “floppy-save” symbol confusing and anachronistic.

Over at Branch, there’s a high-level discussion taking place between designers attempting to actually figure out what a new symbol to represent the “save” function could look like. Some of the ideas include a dot that shrinks or fades inside a circle to indicate how much time has passed between saves, a “donut” that fragments to illustrate points in a “save cycle”, and an arrow pointing to the lemniscate (infinity symbol). All interesting ideas, but all are ultimately a little too complex, too generic, and not particularly fun or friendly.

Those who believe that the floppy cannot represent saving a document because nobody uses real floppy disks anymore miss an important point: while symbols initially piggyback on the meaning we assigned to a material object in order to stand in for something more abstract, once a symbol is used often enough, the symbol itself is enough to carry meaning, and the material object is no longer important. (You could think of the physical object upon which a symbol is based as a kind of scaffolding). This is how all symbols operate, by the way. Once any symbol enters a culture’s visual language, the physical object it was initially based upon is no longer really relevant.

If we look at the floppy disk save symbol, there are a few things to consider. First, it’s a fairly unique symbol: a rounded square with one ‘bevelled’ corner, with two rectangles of differing sizes inside it, the smaller of these with another smaller rectangle inside of it. It’s immediately distinctive, unmistakable, and reproduces extremely well at a variety of sizes. Next thing: the floppy-save symbol is kinda fun, insofar as it references something from ‘another time’. You certainly don’t have to know what a floppy disk is to use the save icon (to you, the symbol may just be “the square with one corner cut off”), but it’s interesting to know that the symbol has a history. So far, there’s nothing really wrong with the symbol. It does its job.

If we’re picking on the floppy-save symbol, we may as well take a look at other symbols to see whether they’re similarly ‘anachronistic’. When we see a stylised depiction of a cog in an interface, we immediately recognise that it stands for “settings”, even though few of us have cranked any heavy cog-based machinery recently. Similarly, I suspect few of us use magnifying glasses to search for physical objects, but in a digital interface, we understand that a magnifying glass stands for “search”. Both the cog and the magnifying glass are fantastic symbols not because we are necessarily intimately familiar with the items they represent, but because they are simple and unmistakable. (I could continue, but I’d urge you to take a look around your screen right now: every symbol you see likely references an ‘antiquated’ physical object, in some way or other).

If we were to replace the floppy-save symbol, what exactly could we replace it with, anyway? It would have to be something distinctive, which rules very basic geometric symbols out (something that looks too similar to a circle wouldn’t work, for example: we already use circles for radio checkboxes, loading spinners, and a variety of other interface elements, and a circle could easily be mistaken for a zero or the letter ‘O’). Similarly, anything making use of arrows should probably be ruled out, as arrows are horribly overused in digital interfaces, and it’s worth remembering the arrow symbol is just as anachronistic as the floppy disk, anyway: it emerged as a means by which to stand in for the abstract concept of ‘direction’ by making reference to the movement of a shafted projectile. We could also look toward other real-world objects that signify ‘saving’, but, because we’re already decades in to graphical UI design, most of the good ones are already taken: a padlock already symbolises security or ‘locking changes’, a chain represents linking, a safe is too difficult to symbolically represent, and other ideas (like using a ‘home plate’) rely on niche cultural understanding.

Certainly, I’m not wedded to the floppy-save symbol, but designers advocating for its replacement need to think hard about how symbols operate and evolve. There is nothing at all wrong with using physical objects as reference points for the symbols we create (it is almost impossible not to). Similarly, we don’t need to worry ourselves too much if the physical object we base a symbol on no longer exists. We don’t need to have shot an arrow to understood what an arrow symbol stands for, nor do we need to own a magnifying glass to know that “the outlined circle with a line poking out at a 45 degree angle” means “search”. If a symbol enters our shared visual language, it can carry meaning on its own. All that is really required of a good symbol is that it is unique, simple to reproduce, and memorable. That’s it. Everything else is icing. The very fact that the floppy has stuck around as a “save” icon for so long may suggest something: the floppy mightn’t make for a great physical storage solution anymore, but that doesn’t mean it’s no longer a damn good symbol.

---

In late 2011, I wrote a piece arguing that Google operated as an applied research lab, with employees encouraged to pursue interesting ideas as ends-in-themselves. Over the past decade, Google’s search engine has basically functioned as a cash cow, allowing the company to develop two freely-distributed operating systems, self-driving cars, augmented reality glasses, and a myriad of other projects, many with no clear revenue stream.

I think this is changing. Stephen Levy’s In The Plex was published in early 2011, and I think that book serves as a comprehensive history of ‘Old Google’. Notably, that book ends with Google planning to launch their social offering, Google+, and prefaces Google transitioning to become a different kind of company entirely.

Google+ is not an Old Google product. Old Google products were defined by compelling features that pushed a particular market forward: a search engine radically better at indexing the web than competitors, a webmail service that provided an order of magnitude more storage than the incumbents, an online mapping solution that defined the market. More crucially, Old Google products often had no real strategic connection to one another: it often seemed as though Google engineers would simply begin by exploring an interesting space, and keep experimenting within that space, testing its limits, forming a product (sometimes in public) as a byproduct of that experimentation.

Google+, on the other hand, was almost certainly spearheaded not by engineers working from the ground-up to make something cool, but from the top-down by executives convinced that Google needed to make its own version of Facebook. That’s why Google+ feels like a refined but incredibly boring product: it’s not something that any engineers at Google would have decided to work on if really given the choice. It’s not a 20% Time project.

The New Google, as Marco Arment suggests, is more strategic, colder, and more focussed. That’s kind of a good thing. It means that the products and services Google produce over the next few years will likely fit together more cohesively, and ship with a higher level of polish (remember Google’s perpetual betas, or – shudder – early Android?).

But that’s also the problem. Creating products to fit into an overarching corporate strategy is not very fun, particularly if you feel as though you have little power to shape that strategy. I think, as power has slowly trickled up to the corporate level, Google will begin to find it extremely difficult to recruit and retain engineering talent. Apple, at least, have always had a strict corporate hierarchy, but Google are still masquerading as though their corporate structure is radically ‘flat’.

A flat structure gets you great, weird products, produced by passionate engineers, and a hierarchical structure gets you a cohesive set of products that work flawlessly. The issue is that I think Google want it both ways, which makes no sense to me. Google have always made a big deal of their 20% Time philosophy, which involves giving an engineer one day a week in order to play around with self-directed projects. But here’s the rub: how can you empower engineers to continue creating weird, cool products in their 20% Time, while at the same time killing existing weird, cool products in a bid to ‘streamline’? Either you tell your engineers they’re free to create cool stuff, or tell them their job is to follow orders from the top in order to create refined, vertically-integrated experiences. 20% Time doesn’t seem to fit with New Google’s obsession with focussing on fewer products in order to “make for a better user experience”.

The real problem for New Google is not that top-down, focussed product development is a bad idea, but that it runs counter to the very strong company culture fostered by Old Google. If Google pretend that they’re still all about empowering engineers to develop awesome, slightly rough products from the bottom-up, they’ll piss more and more of those engineers off once they find that’s not really the case.