-
In the complex decisions between responsive HTML5 websites and native mobile applications, publishers shouldn’t take sides.
The insight of content management systems (going back decades ago to document processing systems and technologies like SGML) was to separate content from presentation.
Somewhere along the line many tools got confused and separated web content from web presentation details.
This is wrong.
Our systems need to make multi-platform publishing — whether it’s to a native iOS application with Newsstand integration, a weekly email newsletter, or whatever best serves the reader — as simple as publishing to the web.
Talk about a “tablet-native” journalism misses the point — of course tablets open up new possibilities in reading. Of course we should create beautiful experiences for the iPad. Of course we should curate our best content for our Newsstand app.
That doesn’t mean we should build brand new systems that do nothing but publish iPad apps.
Multiplicative Solution
We need to address new formats in a multiplicative way — not an additive way.
Each new platform — and there will always be new platforms — can not be a new $100,000 one-off project with new techniques, tools, training and staffing requirements.
We should not be creating a new custom solution for every new platform that launches.
Organizations need to plan and build for a multi-platform future because that is where the audiences will be in 2015 and 2025.
Chasing iPad readers, for example, misses how powerful something as simple as email newsletters still is. Responsive web sites help smartphone users, but aren’t the solution for Kindle and Nook users who are best served with an ebook.
Audiences on post-web platforms want different things than the click-hungry blog readers refreshing pages on their work desktop computers. Our tools need to adapt.
HTML5 Is Part of the Answer
Many people, ourselves included, have long held that HTML is and will be the best solution to these problems. But we’re finding again and again it’s not the whole solution.
While HTML in many ways is this lingua franca, enabling a reasonable presentation layer across devices, simple web pages built with HTML are not necessarily the best experience for all readers of a publication that is more than just a page.
Publications are about more than just articles — newspapers, magazines, books are packages of content.
Packages are more than just content: they are full experiences that include curated content, presentation, and navigation. They had a beginning, middle and end. These are present in the physical packages we use to transmit content. What parts of this experience can we translate into the digital?
Complex web pages — what we now call HTML5 web applications — that use the latest CSS3 tricks and Javascript are simply not sufficient to deliver a background-downloaded NewsStand application on an iPad so a reader awakens to a beautiful new cover every morning.
Even in 2013, beautiful publications with responsive gesture controls, instantaneous page switches, smooth inertial scrolling are not always best delivered in an HTML page. Trust me, we’ve been trying.
HTML may be a great way to represent documents in a cross platform way, but that doesn’t mean we build the tools to read them, like web browsers, in HTML and Javascript.
This doesn’t mean we throw out HTML, or that it’s outdated, just that that it’s only part of the answer.
Our Solution
What we propose is to shift the focus up a level.
Publishing platforms that create these expertly crafted experiences beyond simple web pages — even when they vary by platform — are the next step in the evolution of content management systems. In the same way that our content management system adapted to create RSS feeds, now they must grow to create iPad applications, ePub files, and a myriad of other tools that make reading easier.
XOXCO
XOXCO is building a tool that will enable publishers to create these multi-channel, multi-platform digital experiences. We are now actively looking for forward thinking content producers and publishers to work with. Can we help you? Get in touch.
-
When the term “blog” was coined sometime towards the end of the last century, one of the most difficult problems we faced as an industry was simply how to get more content and more people onto the web. We solved this problem by creating easy to use, web-based content management systems like Blogger and Wordpress to help normal people get their words and pictures onto the web.
This enabled a whole generation of creative people to share their work online. Web magazines, daily opinion sites and independent news sites flourished in this exciting new environment that was hungry for exciting new content. None of these sites, however, made much money.
In 2005, long after the blog had established itself as the dominant form of web publication, the big problem became how to sustain digital publishing as a business. The solution most of us set our sights on on was to generate massive amounts of traffic so that we could sell ads based on our page views.
Sites like those in the Gawker network optimized for page views by increasing the frequency of publishing. Whereas blogs pre-Gawker might post a few posts a day, post-Gawker, the norm for a digital publisher became to publish as many posts per day as possible.
Meanwhile, companies like Huffington Post and companies like Demand Media pioneered the technique of crafting content specifically to lure in search engine traffic - posts written to match trending search topics, so that users would click through primarily to be served an advertisement.
Much to the chagrin of people like me who had been publishing online since the dawn of the web, these new formats and techniques have been pretty successful. As a result, virtually every digital publication launched since then has focused on these goals: publish as fast as possible to optimize desktop web page views and rake in ad and search revenue. The tools used to create these sites, like Wordpress and Drupal, were also optimized to create this type of publication - it is now the defacto standard for websites and content management systems to be organized as a blog, storing and serving content for immediate consumption on the web.
This type of publishing values an ephemeral, passing relationship with the reader — the faster they can be sent on to the next thing, the better. The long term relationship, the loyal readers, the paid subscribers don’t matter nearly as much as someone whose search query lead them to a page hosting the right ad unit.
This year, Wordpress turns 10. Movable Type and Drupal are now 12 years old. In the years since their introduction, we’ve gone from a world populated by dial-up connected desktop PCs to a world in which Apple will be updating the iPad and iPhone twice yearly, and where there are so many flavors of Android device that you need a fancy infographic to explain them. We have e-readers and smart watches and tiny printers that beg for new content. Google, Amazon and Apple have set up huge stores just to sell your content to their millions of customers.
Meanwhile, the market for CPM based ad sales and display advertising is suffering like never before. Publishers and marketers now want engagement, integration into content, and to build a direct and lasting relationship with their customers. Page views alone are no longer enough.
Where does this leave publishers who have invested in web publishing / blogging ecosystem? If our experience working with clients on responsive redesigns and reader aware functionality lead us to any conclusions, it is that these blogging tools are woefully inadequate and out of date in the face of the contemporary marketplace for content. Saddled with complex and customized content management systems, these organizations have a hard time adjusting to the new face of digital publishing, which is much less focused on page views and much more focused on building lasting, loyal relationships with readers.
It reminds us here at XOXCO a lot of those early days of the web — an exciting new environment, filled with customers hungry for exciting new content.
Our publishing tools need to catch up. The web is no longer a medium dominated by desktop PCs sitting on desks, and the world of digital content consumers can no longer be defined as people who read blogs while sitting at work. The tools we use to create these products must evolve to allow us to deliver, present, and repurpose our content to take advantage of these new opportunities.
Does this mean abandoning our investments in Drupal and Wordpress? Of course not! In fact, we think these web CMS systems do a great job at managing content. Where they’ve fallen behind is in producing the kind of premium, reader-friendly end product we need today to stock the virtual shelves of the app stores and ebook stores.
Our proposition: stop making websites, start making native digital products designed for and delivered to the entire spectrum of devices.
XOXCO is building a tool that will enable publishers to create these multi-channel, multi-platform digital experiences. We are now actively looking for forward thinking content producers and publishers to work with. Can we help you? Get in touch.
-
The core idea of reader aware design is that interactive experiences can and should respond to the specific characteristics of a user and their context. Previously, we discussed using details of a user’s relationship with a site — are they a first time visitor, or an every day regular? Now, we move beyond the site, breaking away from a user’s digital context to their analog, real life context: is this person at home? At work? In bed? At lunch? How can your site best serve readers in these different environments?
To enable this kind of design, we’ve updated our reader aware design tool, Aware.js, to provide information about the reader’s local time of day. See a simple demo, or download the code from Github.
Aware.js will now add CSS classes like “morning,” “earlyevening” and “latenight” to a site, empowering designers and developers to create variations in the design and content that relate to the natural cycle of the day. Tapping into these hints about the reader’s context outside of the computer screen will help to improve the visitor’s experience, and offers new opportunities to publishers who want to experiment with packaging and presenting their content for different use cases.
With this new functionality, Aware.js enables features like:
- Create subtle changes to the mood of the site that relate to the time of day - for example, changing the background color or header of the site to match the color of the sky outside.
- Adjust the brightness or contrast of pages late at night, when users are likely to be reading in darker rooms.
- Reflow content to create an “evening edition” of your site, highlighting the most important stories of the day.
- Using Aware’s Javascript reader object, this information can be tied deeply into any web application, personalizing the app’s functionality or interface to be better tuned to the environment around it.
Learn more about reader aware design, and get in touch with us to discuss how we can help your publication or application take advantage of these new techniques.
-
Although it’s not complex technically to adjust presentation or content based on time of day, I don’t see it that often, and it’s still a wonderful little surprise.
There’s something very humanizing about technology that adapts to the time of day in an ambient way.
Because machines by default don’t care! But we do, as people. Real world environments change throughout the day. If they don’t, there’s an uncomfortable artifice to the place, like a Las Vegas casino.
Most software has this uncomfortable artifice, devoid of the natural cycles of the sun that help contextualize our lives.
Painted Ceilings in Software · trenchant.org daily
Adam discusses the use of time of day as a factor in your application and content design. In addition to doing clever things like changing the background color to match the sky, what kind of interesting things might we do with this information?
- Could your site have an evening edition? How about the late night edition?
- Do readers use your site during work hours the same way they use it before and after work?
The natural cycle of the sun is a real part of how and what we do throughout the day. Using this information to assist your readers and users may help to make your site more intuitive and pleasant to use.
Inspired by this post, we will be adding a time-of-day component to Aware.js soon!
-
2012 was an enormously productive and successful year for XOXCO. Though we can’t discuss the details of the majority of our projects, here are some of the highlights:
In January 2012, the brand new, responsive design that we built for The Grammy Awards launched. We worked with our friends at Lullabot on this project - they handled all the backend development, while we built a completely custom responsive Drupal theme from the ground up. See Grammys.com.
Also in January, a new responsive design for Safari Books Online hit the web. We worked with Lullabot on this project too! See SafariBooksOnline.com.
In March, April, May, June and July, the XOXCO team worked with REDACTED to create a Drupal-powered API server, and an HTML5 Chrome application client which used the Ember.js framework. You can read a bit about our experience with Ember here.
In August and September, we worked again with Lullabot to create an HTML5 framework that powers 30 high profile mobile websites for REDACTED. Boy, do we wish we could talk about this one! We built a framework that allows each of these 30 sites to pull in their own set of data from a variety of structured data APIs, several of them providing real-time data, and to present all of this information in an app-like mobile website that can have its look and feel customized via a Drupal interface. Fancy!
In October and November, we built an HTML5 magazine for REDACTED. The magazine is powered by a Drupal API on the backend, and a completely custom HTML5 client on the front end. The work we did on this magazine continued our exploration of using Drupal as an API server only, keeping all of the layout and content presentation in the HTML5 app.
Finally, in November we launched a redesigned and rebuilt Pando Daily, and introduced the world to the idea of reader aware design - the idea that websites can and should look back at their readers. We followed this up with the release of Aware.js, a tool that lets any site become reader aware.
Some broad lessons we learned in 2012:
- The only job your CMS should do is manage content. Stop building PHP theme files and custom CMS plugin hacks to build your website, and let the CMS simply serve up content to a separate layout engine.
- Responsive web sites are great, but technology is moving so fast, and device release schedules are so tight that even the fanciest media queries cannot keep up. Clients do not care about browser makers and OS versions - they simply want their content to arrive in perfect condition. Stop building web sites, and start building platform agnostic content delivery tools.
- Responsive moves in both directions - much smaller screens AND much larger screens. We had two clients who wanted their sites to adapt from 300px wide all the way to 1800px wide.
- Reverse chronological streams of content (that is, the blog format) don’t work as well as they used to. Readers demand personalized, curated and direct access to the content they care about - and that might mean serving them up something that is NOT the newest post.
We are looking forward to new adventures in 2013. XOXCO will continue to work on new reader aware design tools and techniques, and we’ll be engaging directly with publishers to help them go beyond the limitations of their content management systems and traditional web publishing platforms to create exciting new digital experiences. Keep an eye on our blog for more!
-
Last week, I wrote about the concept of reader aware design - the idea that our content websites can now look back at us and alter their layout to best suite our needs as readers without requiring us to login or create accounts.Today, I’m excited to announce the release of the first version of Aware.js, a jQuery plugin that implements many of these features, and enables developers to apply techniques first used in responsive design to these new reader contexts.
What does Aware.js do?
- Adds CSS classes to identify various classes of users: new visitors, repeat visitors, and repeat visitors who are making their first visit of the day.
- Tracks time between visits, and makes this information available via Javascript
- Flags content that is new to the reader for easy CSS styling.
- Inserts relative bookmarks into the content stream to clearly indicate what a reader has already seen.
Once implemented, developers can drastically alter the layout of their site using only CSS to accomodate a wide variety of reading scenarios. Combining these new CSS and Javascript tools with existing responsive design techniques unlocks a vast array of options for customizing the layout and content on a page to suite individual readers without requiring any server-side code or CMS template logic. View a demo of Aware.js in action here.
Learn more, and download Aware.js here.
We’re releasing Aware.js now to continue the conversation about reader aware design, and to collect feedback and suggestions from the community. What other information might Aware.js provide about a reader? How will you use these tools and techniques on your site? We’d love to hear from you - Send us a tweet to @XOXCO!
-
Update: We released Aware.js to help make your site reader aware!
We now use the internet on a diverse set of devices, and these new devices afford us opportunities to read web material in contexts far beyond the traditional desktop monitor.
Instead of nervously reloading our favorite blogs throughout the day, we might choose to read the news once a day, in the evening on our tablet. Or, we might check catch up via e-reader a few times a week while offline on the train. These different reading contexts give us clues as to how the person is using the site, and what sort of content makes most sense to present.
Presenting everything as a reverse chronological stream of posts made sense when we knew our readers were sitting at a desk, hitting reload on 30 tabs all day long at work. Does it still make sense when content arrives on an e-paper watch, an Xbox or a tiny slip of paper?
Meanwhile, enormous piles of data are being collected about our browsing habits. When do we visit? What have we visited recently? This information is squirreled away in the cloud in order to better sell us things. Instead of just handing all that data over to Google and Facebook and Twitter, sites should leverage some of it to enhance the reading experience.
In addition to becoming device aware through responsive design techniques, our sites should also strive to become reader aware.
-
Our friend Mat Honan experienced a monumental attack on his digital identity last week. He’s written extensively about it on his personal site and for Wired, and appears above in a clip from CNN.
The short story is, hackers were able to gain access to his accounts, not by guessing or brute forcing his password, but by calling into the customer service lines of Amazon and Apple, where employees of these companies happily handed over access to his accounts in return for a few tidbits of easily collected information. After gaining access to one account, the hacker was able to quickly gain access to several others, including Mat’s Gmail, Twitter, Amazon and Apple profiles, using password reset tools. As a result, Mat has concluded that our current assumptions about web security are woefully out of step with the intertwined nature of cloud-based services:
“The disconnect exposes flaws in data management policies endemic to the entire technology industry, and points to a looming nightmare as we enter the era of cloud computing and connected devices.
…
“Password-based security mechanisms — which can be cracked, reset, and socially engineered — no longer suffice in the era of cloud computing.”
So, what impact does this have on my password-less login idea that relies on the same mechanism as the password reset tools that ruined Mat’s week?
-
Since Hacker News and @lukew tweeted links to my password-less login post this morning, almost 400 people have tweeted about it and sent in their feedback. There is a nearly 100 message thread on Hacker News discussing the various strengths and weaknesses of my suggestion. Opinions are too varied to attempt a summary, but there’s a lot of good thinking going on in this thread. Here are a few follow-up thoughts and responses to some of the comments I’ve received.
Are texts or IMs better? My big brained studio-mate Patrick suggested that a text message might work better in some cases than an e-mail. Someone else suggested sending an instant message. There are definitely benefits to using texts or IMs, such as the fact that these get pushed to the user in a more direct way than email does. However, sending email is very easy for developers to do, and sending text messages and IMs requires interfacing with potentially complex third party APIs.
The reason I originally suggested email as the conduit for these links is that it is there is no need to rely on third party APIs or tools - virtually any development platform can send email with little or no configuration.
Is it possible to do this via text, IM, push alerts, or heck, by sending private messages on Twitter? Sure! I would encourage developers working in these areas to give it a try. But email is simple to implement, and is already being used for 2 out of the 3 login processes we all do every day: email verification and password reset.
But seriously, why not Oauth? A few people told me that I was being too harsh on Oauth, and that logging in via Twitter was already easy enough. And then Twitter went down or three hours, and nobody was able to login to anything. Meanwhile, the leader of the Oauth 2.0 specification process quit because he feels that Oauth is headed in the wrong direction. Don’t get me wrong, I think Oauth is very handy and works fine for a lot of places, but because of developer complexity, shifting specs (how many times do you want to re-implement a multi-step handshake?) and changing end user preferences, I think email makes a very nice and safe alternative.
How about use my browser, my phone, or a USB dongle to identify me instead? For exactly the same reasons as above. As a gadget nerd, I think that being able to login to my account using a a hyper-secure NFC handshake with my phone would be super cool. But for purposes of developer ease, user familiarity and because its available today as in right now, I think email still wins. But ok, yes, Mozilla Personas looks kind of neat, OK?
“But email is not actually instantaneous!” said several people. True, but it is most of the time.
“But what if I want to login from a friends house and can’t access my email?” said a few other people. I think this is a pretty small edge case, but if you are really concerned with this scenario, I’d suggest providing a password-based backup. Hacker News user “woah” suggested a brilliant compromise: simply reverse the order of the password reset tool and the password field on the form. Users who don’t want to use passwords can get a link sent via email, and users who do (or can’t access email for some reason) can login in the traditional way.
Regarding my suggestion to autocomplete usernames - @srslyjosh reminds us that exposing email addresses is a bad idea for a variety of reasons, including spam, phishing and others. You should never reveal a user’s email address! My suggestion is to allow users to type either their username or password, but to show only a user’s “real name” or non-email username in the drop down menu.
Finally, I saw an implementation of a similar login system already in practice at LaunchRock.com. To create an account and get started, all you need to do is enter an email address. Once you do, you’re logged in and ready to go. You’re only required to set a password - via a password reset tool - if you somehow get logged out. Nice!
-
Logging in to web sites is ironically one of the most difficult tasks put before our users. Usernames and passwords are hard to remember, and harder than ever to type on the tiny on-screen keyboards of mobile devices. Even large, successful websites report that they receive an outsized number of support requests pertaining to login problems. We need something better.
As multi-device software developers, we’re interested in making these login processes as simple as possible. If you want to access our products on multiple devices, why should you be required to login with a username and password on each device? What a pain!
My personal solution to the too-many-password problem is to use completely random, automatically generated password when I create an account. Most websites will allow me to stay logged in forever, and on the odd occasion that I need to log in again, a password reset tool will send a link to your email account that will allow me to login again. This way, I don’t really have a password, but I can always gain access to any account, as long as I still have access to my secure email account.
Here’s what login form looks like now:
Facebook login has 6 different controls you must interact with before logging in.
Yahoo has 9 controls on their login form!
Since a user may or may not already have an account, we have to offer the option to join as a separate choice. Existing users must remember both their username and password. In many cases, an invalid combination won’t be revealed until after the form has been submitted, forcing the user to re-enter both the username and password. And if they still can’t remember, it’s off to the password recovery tool.
In the best case scenario, our expert user is able to login with one attempt. But in many cases, the user will be required to type these values multiple times, and may ultimately be sent off to their email client anyway. When creating an account, the new user will almost certainly be sent to check their email in order to validate their email address.
At An Event Apart, @lukew talked about a login design pattern where the username field would autocomplete, allowing a user to quickly select their name from a list instead of typing the whole thing. Then, once a user has successfully logged in once, the site can at least remember the username forever, offering it next time as a choice.
(An argument could be made that it is bad practice to tell random strangers what is and isn’t a valid username, since this makes it easier to target only valid usernames during break-in hacks. However, considering that most services these days already expose a directory of users via profile pages and friend finders, this is in my estimation not a significant risk.)
This is a step in the right direction, as it only requires the user to remember a password. The application can also adjust accordingly if a matching username cannot be found, pivoting from login to account creation.
But we’re still requiring users to remember an eight-character string of nonsense — or more likely, we’re encouraging our users to “secure” their account using a password like “password” or “123456.” (See http://www.lukew.com/ff/entry.asp?1590)
No More Secrets
I think an even better solution would be to remove the password completely, allowing users to login with only an email address. Each time a user needs to login, they enter their email address and receive a login link via email.
Combined with @lukew’s suggestion of pre-populating the username field, this design would allow existing users to login with only a few clicks and no typing - select an account from a list, click a link, and they’re done. For users who do not already have an account, the process is the same - they will type only their email address, and receive a link via email. This email logs them in and validates the email in one fell swoop.
In addition to making it easier to login, this authentication system could be built to allow the login link to be used on multiple devices. Imagine if your new users only had to enter an email address one time to login to your software on their laptop, phone, tablet and any other device they might have. The login link could be extended to work with native app URL-handlers, so that the login link could automatically launch a native app and pass in authentication details at the same time. With web apps, it couldn’t be easier - with one click, the user logs in and launches into your experience, continuing exactly where they left off.
But what about…
Keep in mind, most services already send new users out to their email clients to validate their email address before gaining full access. And we know that a shockingly high percentage of returning users will need to use the password recovery tool to login. In a best case implementation of this pattern, where cookie expirations are set for the distant future and your users do not frequently reset their browsers, it would be possible for a user to login to your service on multiple devices and stay logged in forever, having typed their email address only one time.
There are existing systems that allow users to login without usernames and passwords, oauth being the most popular. Oauth enables users to login using an existing account from another service, like Twitter or Facebook. But logging in with oauth carries with it all sorts of unknown and potentially undesirable consequences, like granting access to friends lists and social networking profiles. It also hands over the keys for your service to a third party, putting your app and users at the whim of external downtime and API changes. And while oauth seeks to simplify login, it is likely that your users will be sent to the third party service, be required to login with a username and password, and then be asked to review and approve complex and frequently misleading permissions for your app before being sent back to complete the login. Is that really easier?
As a developer, there is a another incentive for not collecting passwords: you no longer have to worry about storing passwords in your database. This doesn’t excuse you from running a secure service, but it reduces the number of things you need to protect. Wouldn’t it be nice to know beyond the shadow of a doubt that you will never be responsible for a massive password leak?
To keep things secure, the login link sent via email should have a limited life span: usable only once, or for a short period of time. These links may be stored in a browser’s history, or in a proxy or caching system. And we must keep in mind that this whole process assumes that the user’s email account is and will remain secure - this is the same assumption that most password reset tools already make. With these considerations in mind, I wouldn’t recommend going password-less for anything too sensitive.
I am currently planning on implementing passwordless login for SendTab, which will hopefully make it drastically easier for users to get up and running on multiple devices. What about your apps? Can you see a world without passwords? Tweet your thoughts at @XOXCO.
Further Reading
I posted a follow-up to this essay after nearly 400 tweets about it. Read it!
Read @lukew’s post about login difficulties, which links to this Arstechnica discussion of how passwords never worked.
This is a post from XOXCO's company blog. XOXCO is a product design and development company based in Austin, Texas. We create apps, write code, and provide design consulting. Follow us on Twitter or visit our site to learn more.
