The Unfinished Story of Words by sven 12 Mar 2014 Warning: Long Article :). table of contents The Unfinished Story of Words table of contents chapter 1 -- the whole story First Words iteration Second iteration Words Third iteration Words Fourth iteration Words time to get real Read it Later First iteration Words Read-it-Later Second iteration Second Iteration Article View Final Version Words 1.0 Words 2 first iterations Words 2 second iteration Finally, we launched Words 2. we got beat The Future of Words what is missing? discovery action Our future focus for today chapter 1 the whole story As you may know: Words is a Mac desktop Read-it-Later client, brought to you by my father, my brother and me. Everything started back in September 2011. I loved to read. And I specifically loved to read eBooks. On my iPhone, on my early iPad or sometimes even on dead wood. What bothered me: All of these channels made it difficult for me to make use of their content. A lot of books I read back then centered around CSS and web design in general, often containing multiple code examples. And it really sucked hard to get those examples on my desktop to work with them and see the results with my own eyes. I needed a decent ePub client to get my book content on to the desktop. I didn't want to transcribe it, character by character, just to see that it worked. But there was no such client available. Well, that's not excatly true. There was Calibre, which was (and still is) really ugly (no offence, ... but hey!). And back then iBooks was far away. So started to dream up my version of what such a client should look like and how he should function. Have a look at my very first prototype: First Words iteration http://zenmagiclove.com/zml/suite/suite.zml Second iteration Words The second iteration changed quite drastically. I wanted to simplifly the reading experience and reduce the necessary UI: http://zenmagiclove.com/zml/suite/suite.zml I didn't have any experience at all on building a desktop application. So I dreamed wildly. By the way: I built all these prototypes in HTML & CSS. And I imagined, logically, that building an app in native code must be even more powerful and easy. Third iteration Words http://zenmagiclove.com/zml/suite/suite.zml I decided that I didn't like this left sided small text preview to navigate a book. So I invented an interesting topographic text map to navigate it. This UI element alone could be worth an blog post of it's own. You can see it at the bottom of the following prototype. Even today I feel that this is a awesome way to give you a sense of location on your journey through a long and winding story. Fourth iteration Words http://zenmagiclove.com/zml/suite/suite.zml At this stage no developer had seen these prototypes yet. But it was time to get real. time to get real I talked to my father, an old school self-taught developer who built a few apps for the Symbian mobile platform, loves linux and once made a sweet browser game (I think it was called "New World" or something similar). I pushed him into Objective-C, Cocoa and using a Mac. He liked the idea of building an reading app, but didn't exactly like the platform (they are good friends in the meantime). He now even has a own Macbook Pro and an iPhone. But reality caught up with us fast. We had to learn that the ePub standard was a bloody mess and it seemed that it would get even worse in the near future (I am looking at you, ePub3). So we decided to go for the low hanging fruit instead. Read it Later I loved using Instapaper on my iPhone. And I was suprised to see that there was no client to access my articles on my desktop enviroment, too (yes, I know, they had a browser app). And they had something close to an API. So I changed my plans and we switched to an Read-it-Later client instead of an ePub client. And this was the first result: First iteration Words Read-it-Later http://zenmagiclove.com/zml/suite/suite.zml Further investigations uncovered more suprising circumstances: Instapaper wasn't the only Read-it-Later service. For the first time I met Pocket and Readability. We wanted to integrate them as well. And I wanted to simplify the experience more. Slowly, Words started to develope into what would become it's first public version. Second iteration Second Iteration Article View http://zenmagiclove.com/zml/suite/suite.zml After some time developing we had to makes some compromises on the design, due to both my father and me being completely new to mac development. XCode made us want to kill somebody! We just couldn't figure everything out in time. This stuff was far more complicated than we had expected. But we finally managed to get the basics up and running. We cut out most of the additional features. So this is what the final version looked like, back in July 2012: Words 1.0 Final Version Words 1.0 http://zenmagiclove.com/zml/suite/suite.zml We where proud as hell as we launched our first, own, homemade app into the still young Mac Appstore. And we had absolutely no idea how we should handle pricing, updates, bugs, complaints, reviews and marketing in general. We learned by doing it. Probably the most effective way to learn. But sometimes it drove us up the wall. We had lots of small bugs and incompatibilies that we hadn't thought of in advance. Even a case sensitive file system could crash our app. We shipped lots of small updates to fix them. Additionally, I had made a few wrong assumptions. Words was built to focus on reading articles, and nothing else. The Read-it-Later services simply delivered the content into the app. Nothing more. But, unsuprisingly, users wanted to manage their Read-it-Later accounts completely. Archive, favorite and move their articles into folders. That meant a complete rewrite of our engine and database. Additionally, most our users disliked the separate window approach. Consequence: We started working on Words 2. Words 2 first iterations http://zenmagiclove.com/zml/suite/suite.zml We planed on unifying the article view and the article list into one window. Additionally we needed far more UI to handle the growing options users now had. Above is the first iteration, with a slim sidebar to the left. My intention was not to differentiat between the different services, only between the states an article can inherit (like favorited, archived, etc.). But things started to become ugly. Only Instapaper supported folders. Pocket and Readability had tags, Instapaper did not. We tried to emulate the features for the services that didn't have them, to give them all the same feature set. It wasn't fun to make this work. The left sidebar needed more room to display folder and tag names. So Words evolved further: Words 2 second iteration http://zenmagiclove.com/zml/suite/suite.zml Additionally, I wanted to make sure that Words could still be operated in an article-only mode. This should ensure an undisturbed reading experience. So we introduced buttons to fold the left and right sidebar away. And we tried to build it in a way that if one sidebar was open, the other one would close automatically. This should help garantuee that the article always has a enough space to be read easily. My farther experienced many long nights on fighting this problem. And I thought it would be easy. We decided on using MacGap to build these sidebars and the article view with HTML and CSS and let everything talk to the Obj-C code easily. This seemed like the easiest and most time efficient way to go. We added my middle brother to the team (Hey Kev!), as an expert in JS and web development. In retrospect I would change quite a lot of decisions we made back then. But this one point would be right up on the top of the list. It worked, but it caused us a lot of headache. And it never really felt native. I regret it strongly going down this path. And we tried to jump the RSS bandwaggon as Google Reader announced it's dimise. But we didn't want to handle even more API's (we already had enough trying to fight Instapaper, Readability and Pocket). So we decided to take a different approach. We add our own RSS engine that fetched the feed items URL's and rendered the full article like a Read-it-Later serivce would do and present it to our users. We had some concerns if RSS really would fit our initial plan for the app, but in the end we went for it. Today, I would decide differently. I eventually even made a full scale CSS framework to display the articles in various themes. I called it "Out of Words" and it is available on Github, if you want to take a look at it. It may be a bit dated in the mean time, but it works. Most interesting feature in my opinion? The multi-column article view: Mulit Column View http://zenmagiclove.com/zml/suite/suite.zml Finally, we launched Words 2. We added lots of additional features, like RSS feeds automatically rendered into full Read-it-Later style articles, Multi-Column article view, dark and light reading themes, even different font themes and responsive font sizing (depending on the screen size available). Words 2 launch image http://zenmagiclove.com/zml/suite/suite.zml we got beat But, despite our best effort, we got beating by Readkit. They happened to be faster to finish their client. It was completely native and more stable, felt more natural. And they featured every RSS service on this planet. They did a good job. We got a few things right and we decided a few things badly wrong. We had our shot. And we missed. No regrets. After the launch we fixed the bugs (our Obj-C/HTML/JS mixture proved a bit unstable at times) and iterated a bit on the design to make it more friendly. Sidebar redesign http://zenmagiclove.com/zml/suite/suite.zml The Future of Words All these bug fixes couldn't solve our most basic problem. We had lost our justification to exist. And it gets more obvious every day. Back then, as we started out, Words was the only Read-it-Later client. So we offered a solution to people who wanted to use their Read-it-Later content on a Mac desktop. This isn't the case anymore. There are dozens of clients around now. Additionally, Read-it-Later services in general have lost a lot relevance during the last few years. Most websites aren't unreadable and distracting anymore. I, personally, have stopped using them. This kind of service mostly just isn't necessary anymore. This wouldn't have been a big problem if we hadn't left our path. Back in the days my inital goal was to create the best reading experience on the Mac. But we got distraced and have become one of many Read-it-Later & RSS clients. This decision was wrong and it is my fault. And I want to correct it. I want to return to our root idea. To make a better reading experience for our users. what is missing? So what is missing in our current reading experience? Actually, just presenting an article I already selected as interesting isn't what I need most. It is just one, short and mostly overvalued moment during the process of reading. There is a lot that needs to happen until I can read a good article. And what happens after I read an article? These are the two big areas where we can improve future reading experiences: discovery Discovery: The most obvious area. And the most difficult. Today most of us suffer from information overload. We don't lack possible sources of information, we have to much. And it is time consuming and often difficult to find the quality in our daily stream of content. This would be an interesting area to get into. But, without doubt, one that is very difficult to make a real difference. Many smart people before have tried to solve intelligent content delivery. And none really made advancements worth mentioning. My brother Kevin made a passionate stance against this option. And I now agree with him. This is by far to big for us. action Action: What happens after I read an article? Was it worth saving for future reference? Any knowledge worth keeping? Do I need this soon in some project? And how should I organise my references? This is a completely unresolved area. There is nobody to save us from our endless lists of previously interesting articles. Everything just gets lost in a sea of list items. As far as I know there are only some (previously famous) bookmarking services that try (not very successfull) to organise my collected knowledge. I would love to have something that helps me take action on something I just have read. Now, later, someday. Or just archive it away for some feeling that tells me that this could come in handy in some future time. And make it possible to find it, if I need it later on. Our future focus The second area is what Words 3 will be focussing on. You can still have your Read-it-Later services, but they will only be content delivery sources, as well as your RSS feeds. And you can just drag in articles from your browser. Perhaps even from your Twitter feed. All just sources. Your content will get rendered to provide you with a distraction free reading experience. But the focus will be on quality content you want to keep and organise easily. To take action on. To reference it later. To take notes. To find your information if you need it. To make good use of the time you invested in finding and reading worthy content. for today Today, the approach that the Getting-things-done people use seems to work for organising knowledge, too. But we are still in the process of testing things and I don't want to go into to much detail yet. But it looks promising and I hope you are as excited as I am about us returning to our roots. To help you in getting the best experience from reading. What do you think? Tell me per mail or on Twitter.