google

Developers: stop re-AOLizing the web!

/ Josh R / 19 Comments

No AOLI recently succumbed to the hype and downloaded Mailbox, a mobile email client that tries to help you manage your overflowing email inbox and achieve the mythical “inbox zero”.

Mailbox does this by encouraging you to immediately archive, trash or schedule the email for a re-read or response using a swipe interface. It’s pretty good, actually, and I’ve found myself with fewer new emails just sitting in my inbox waiting for me to do something with them. My older email archive is another matter.

There’s one major flaw however.

By using Mailbox, I’m effectively helping to re-AOLize the web. You see, Mailbox only supports two email providers: Gmail and Apple iCloud.

I find it incredible that an app developer working on an open, well-documented and well-understood platform like email has effectively closed down access to their product to users who are on just a couple of providers.

Don’t get me wrong: I know the problems are difficult, especially as open platforms beget a multitude of implementations.

But by choosing to lock yourself into the Google API, when there is another, really open way to do things, feels like a mistake to me. If Mailbox supported any standardised IMAP provider, they’d no doubt have access to a much wider user base who would use their app across multiple providers.

And they might even be able to charge for the app and make an income – rather than selling themselves to Dropbox to survive.

It doesn’t help that locking me even more to the Google ecosystem and all the threats to my privacy and freedom that brings with it. Dropbox is another cloud company with a questionable approach to customer’s privacy and freedom.

Google (and to a lesser extent) Apple, Facebook and Twitter, have little interest in allowing their products to inter-operate in a meaningful way. Let’s remember that this is exactly how much of the consumer internet worked in the late 80s and 90s: CompuServe only reluctantly added email to its internal messaging and AoL generally preferred to lock down users to its own walled-garden of content rather than having them access the web. Both these networks, once seen as pioneers are now effectively defunct.

When developers choose to lock-in to an ecosystem like Google, they also lock in users. And that’s when innovation dies: users’ choice is restricted, so they demand less (and alternatives don’t get developed). By using it myself, I’m helping depress demand for a good email client that works with multiple providers. That’s not a good thing because it means I’ll have less choice.

Despite email being an inherently tedious form of communication, it’s essential and here to stay. If developers want to play their part in improving email, then it’s not going to be by re-AOLizing the web and locking down to a single provider: it’s going to be by supporting open email platforms that enable a wide range of people to use your product.

As it stands, Mailbox has been a useful so far. But I know my own time with it is limited, as I continue to transition away from closed source, anti-privacy services like Gmail to self-hosted, free and open source alternatives.

And that will be a loss for the Mailbox developers.

Google Chrome’s “Warn Before Quitting” preference doesn’t automatically sync

/ Josh R / 2 Comments

I recently set up my new work Mac and one of my first tasks was to download Google Chrome. Yes, Google is ‘evil’ and gives away my data to the NSA, but you can’t beat the convenience of having a synchronised browser experience across multiple computers.

Signing-in to Chrome with my Google account lets automatically install my preferred extensions, synchronises bookmarks and history (if I choose) and other browsing preferences.

Warn Before Quitting in Chrome

However, the most useful preference that I have enabled does not get sync’d. That’s “Warn Before Quitting” – an incredibly helpful feature for those with fat fingers like me, or if you’re just someone that types very fast. Tapping Command-Q on a Mac is the standard keyboard shortcut to close an app, but unfortunately it’s right next to Command-W – the command to just close a window or, say, a Chrome tab.

The Warn Before Quitting feature requires you to hold down Command-Q for more than a keystroke to quit Chrome. In fact, you have to hold it down for a few seconds while a visual prompt confirms you really do want to quit. And given how many tabs I usually have open at once, this is quite rare.

So while this is a great feature, the second-greatest feature – syncing – doesn’t actually enable it on other browsers! I suppose this is partly down to the cross-platform nature of Chrome – the equivalent key combination on Windows, Alt+F4 poses fewer issues.

Nonetheless, a pretty key preference for Chrome Mac users is not sync’d across devices. And I’ve been losing tabs for days!

What’s planned for Ancoats? Local planning applications live

/ Josh R / Leave a comment

As denizens of Ancoats, we know that it’s constantly undergoing redevelopment and change. Things are stopping and starting all the time, though recently it seems some projects are going to be finished after all.

There’s loads of marketing guff out there about what’s coming next, but the definitive source is planning applications. Thanks to our friends at Planning Alerts, we’ve put together a map of live planning applications in the local area.

As this is based on Google Maps, you can of course, manipulate it like any other Google map – switch between the different view modes and even play with the Street View mode. This lets you click on any planning application and immediately see the building in question.

While we try it out, the map is centred around the middle of Great Ancoats Street and shows nearby applications to a diameter of about 800 metres. We’ll tweak this in the coming days as we get feedback on how useful this is and what you want to see on it.

So try out the local planning applications map and drop a comment here with any feedback!

Creating a free issue tracker using Google Docs & Spreadsheets

/ Josh R / 9 Comments

I recently launched a WordPress-based microsite for a project that is a partnership between my workplace and two other charities. As the digital project manager, I had to manage queries both the internal and external stakeholders, all of whom were keen that the inevitable snags were dealt with as rapidly as possible by myself or the developers as appropriate.

It’s very easy to drown under a weight of emails with different requests, of varying priority and ability to fix. I needed a quick way of letting people input their issues into a central store, without needing to login or navigate anything that looked remotely scary. It had to replace sending an email to me.

Here comes the Twitter bit…

I put out a call for a free bug tracker on Twitter and got a number of useful suggestions (Trac, Uservoice, Getsatisfaction) but none of them quite fit what I wanted to do. I also ran a Google search and got a couple of solutions, that required a bit of sign-up and configuration. Thinking further, I realised that a Google product that I had almost never used was actually the answer.

Creating the issue tracker

Google Docs & Spreadsheets logoGoogle Spreadsheets is a free online spreadsheet system that is designed for collaboration from the ground-up. Using your inevitable Google Account, you can quickly create and publish spreadsheets to either an invite-only audience or to everyone who has the link.

Within minutes, and with Dave Mee‘s advice, I’d set up a basic spreadsheet that covered off all the key things you’d want to know if you were tracking bugs. Using the ‘Share’ button, I can create a link like the one above and let anyone look at it, or even edit it, without signing-in. For the purposes of demo, you won’t be able to edit the sample tracker, but please click ‘File / Create a Copy’ for your own version.

Keeping it simple (stupid)

Unfortunately, sending users to a spreadsheet isn’t the most friendly interface to provide them with. Remember, I needed this to replace email so that means users need a simple, easy-to-understand method to put data in there, without logging in.

Well, the great thing about Google Spreadsheets is that it can act as a basic data-collection platform. This is key, because you don’t need to share the spreadsheet and all the data stored in it in order to get data into it, nor do you need users to login to yet another system.

From the spreadsheet above, the obvious ‘Form’ menu option, I was able to quickly create a simple form that automatically updated fields relevant to the end user. For example, I wanted users to tell me the problem (Issue detail…) but I would be setting the priority level and assigning it to the right people for resolution. During the creation of the form I was easily able to edit how all the fields are displayed and whether they’re required – and delete the fields that users don’t need to see.

That form can now be emailed around to anyone relevant or embedded within another webpage, say a feedback form on a beta/testing site or even on an organisation’s intranet. It’s trivial to further configure the spreadsheet options to email you whenever anyone then adds an entry to it via the form.

Love and spreadsheets are free

Total cost of this endeavour? Zero, apart from my time which was approximately 30-45 minutes, allowing for my fiddling around. Now that all requests for fixes are routed through one place, they can be managed much more easily and transparently, saving time and with users being able (if you wish) to monitor the fix status of any issue!

Found this useful? Am I missing out on a better way to capture these issues? Leave a comment below…