I’m currently listening to Episode 92 of the Build and Analyze podcast with Marco Arment and Dan Benjamin. The general theme of the first half of this episode centred around the idea of taking a well-established company, such a Twitter or Dropbox, and turning them into a $40bn like Facebook, prompted by a discussion about how Twitter is currently making changes (Creating a “consistent” user experience; limiting the user-base to 100,000; making Twitter more app-agnostic).
Surely this means that any client like what we’re useful will become bland, and exactly how Twitter want it if the developer wants to stand any chance of being allowed more than 100,000 users by the all-controlling Twitter.
Maybe this will mean that the only innovation will occur in much more niche apps, such as perhaps those used by companies wanting to monitor public perception of themselves using a combination of the REST and Stream APIs.
At present I’m using 14% of the 3.5GBs of Dropbox storage that I’ve got without spending a penny, and I see absolutely no reason why, as an individual, I’d want to pay for a “pro” account, which is not really much more than a bigger bucket that I can chuck stuff into. Having one big lump of storage just doesn’t suit the way I like to work. Assuming Dropbox don’t make enough through selling their “team” package, and they don’t really have enough information about their users to sell well targeted ads (Even then they’ve got to manage to do so in a way that won’t piss off users and send them off to Google Drive), the only way they can ever dream of becoming a Facebook-esque $40bn company is by getting a lot more regular users to pay for their storage.
The most frustrating thing about Dropbox is that I’d love to use it all over my home directory. There’re so many folders within my Documents that could do with being accessible anywhere, but it’s a hassle to duplicate things into this seperate magic bucket, that syncs so seamlessly and without requiring any thought on my part. Why, oh why haven’t Dropbox allowed for multiple folders to be created wherever users want yet. I’d certainly pay for that, and I’m sure others would too. I only use the Dropbox web interface when I’ve got to access something in an emergency on an unfamiliar computer, and in that situation I don’t mind that my beautifully organised filesystem has been flattened so all my little buckets sit within the same root directory. I’d have (the one and only working copy of) my CV available whenever, without having to rember to copy-and-replace the version I currently have in ~Dropbox everytime I make a small change. I wouldn’t have to push git repositories to another location on the same harddrive just to get them to sync (For argument’s sake we’re going to assume that if I’m allowed multiple Dropbox buckets, I’m also allowed .ignore lists, so I don’t have to send all my intermediate files up to the cloud too) and I don’t need to synchronise throwaway files that I’m creating just to try something out quickly.
Twitter seems to be becoming increasingly hostile to developers, but without them it’s hard to see how it could become a sustainable big-money business. It needs to keep its users engaged, and without a variety of apps, and a seamless (ad-free?) way of consuming Tweets, I just don’t see them hanging around for too much longer.
I think Dropbox, on the other hand, has much more potential. If they can create a top-notch premium product, that they can sell to the masses, they stand a chance of moving on to bigger things. The logical next steps once there’s a bit more cash flowing in may well be to get Developers to use Dropbox more, perhaps by offering a Document-based storage API, so users can still feel in control of the files produced by apps whilst they’re simultaneously “in the cloud”.
But then you have to wonder whether it’s really in any of these companies’ interests to become a new Facebook. Afterall, things haven’t exactly been perfect since their IPO offerring, at least not financially. Maybe Dropbox is quite content providing free storage for the masses, and should Twitter just concentrate on their content, as after all, it’s that that’s king.
]]>I never used to like the idea of link-blogs, such a John Gruber’s Daring Fireball, where the majority of posts have title which are links to content on other sites, and the post body is a brief commentary by the linkblog-owner.
I think the biggest problem that I have with Daring Fireball is the confusion I had when I first visited it. The homepage presented a list of posts that sounded interesting, and whilst I was scrolling through I was Cmd+clicking on the titles of articles that I’d like to read to open the link in another tab. Once I’d finished this filtering process, I was rather suprised that I hadn’t got a collection of Daring Fireball pages open, each containing Gruber’s content as I’d seen it on the homepage of his site, but all the sites that Gruber had linked to without his commentary. Compared to reading the longer-form traditional blog posts on the site, where you’d typically click on the post title or a “read more” link to get to the full article, these link posts have to be read from the homepage (Or clicking the faded star next to the post title to access the permalink) before clicking on the title link to visit the linked site.
That said, I am finding myself wanting to express an opinion on things I’m reading more and more frequently, and reading Arstechnica’s SSD article yesterday on the train yesterday afternoon I finally decided to give it a try, particuarly as Octopress is now previewing its linklog feature. In the past I’ve shared my thoughts on web content on Twitter, and whilst I find being limited to only 140 characters can really focus my writing, sometimes what you want to say really won’t fit into so few words.
It does feel like a somewhat lazy way to generate content, and unless I feel there’s a clear point that I can make or add, I don’t want to just link to stuff I’ve found that I think is cool or interesting. As mentioned before, you can follow me on Twitter for that. The reason Daring Fireball has such a following is because Gruber has a proven track record of being able to analyse articles on the web, and people are genuinely interested in his opinion (Hence the phenomenon of sites getting fireballed when he links to them). For this reason, these link-style posts will not be that common for now, but they’re something I’ve definitely grown to appreciate over the last few years.
As I’ve mentioned previously, I do like the Octopress classic theme as a good default. It’s clear, modern, and flexible, allowing for content customisation to be added through widgets, and colour changes to be made by overriding stylesheets. Whilst I still think it’s a very good theme to ship as a default for new users, I’m starting to want to make more and more changes to it, and not just through updating the sass. For this reason, I think I’m going to have a play at creating my own theme, but using the default classic theme as a starting point.
The development of this modified theme will take place on GitHub, but essentially I want to work on a few key areas initially:
This is all the stuff that could be done by overriding the existing style sheets. Whilst I think the default colours look good, my initial approach of just modifying the header colour was blunt, and a number of other colours need changing to really unify the design (The blue mouse-over colour of the “Read more” link, for example). Generally, the colour scheme just needs finishing.
Whilst I like the current approach of the Octopress in allowing for flexibility in how the titles of link posts are displayed (I have mine slightly smaller than the titles of regular blog posts, and with a → preceeding the title to try and make it obvious that the link does not go to a page on this site), there are a few modifications that I want to make to the format of meta information:
whereas I think something like“Posted by Edward Armitage • Jun 12th, 2012 • meta, octopress”
“Posted by Edward Armitage on Jun 12th 2012 • Categories: meta, octopress”
is more clear.
I don’t much like the fact that the sidebar can be hidden, as I don’t see much point in it. I can understand the benefits of creating an uncluttered view of the page for easy reading, but removing the sidebar creates uncomfortably wide lines of text for me, and I’m only using a 13” laptop. I hope that the content on my site is present in a way that makes it easy to read, and for those times when you really do want an reading experience without distractions there’s always Instapaper or your browser’s full screen reading mode.
My main issues with the header are that the navigation looks too seperated from the main header banner, and the RSS icon appears to be a stylistic addition to the search box’s input field.
Finally, in order to make my blogging process as productive as possible, I’ve been working on developing a Ruby application called Squid-Ink. I’ll post more fully about it at another time, but essentially it’s a tool to manage Octopress blog posts using a command line interface similar to that of git. It’s written in Ruby, so the dependancies should largely be the same as those for Octopress itself, and it’ll hopefully be distributed as a gem, if I can figure that out.
I never really considered using a blogging engine that didn’t use a database until recently, when I read Matt Gemmell’s blog post on using Octopress and suddenly I got it. His writing had me just interested enough to visit Octopress’ site, and from there I started to realise that there’s a lot more to the Octopress framework than simply applying a stylesheet, a header and some widgets around some html that you’ve had to generate yourself.
The fact that it’s static obviously has an advantage in terms of me being able to version the content, and although at present this isn’t something that I’ve got setup, it’s the very next thing on the ToDo list. The Octopress framework itself is hosted on github, and it’s been designed with a reasonable amount of care so that upgrading should be as simple as pulling the latest version from the remote repository, because all user generated content (ie. blog posts and page contents) are kept away from the voodoo that drives the jekyll engine underneath. The only reason the content is currently properly versioned is because of my lack of knowledge with how to best set up branching in distributed VCSs, rather than any problem or complications with Octopress.
At present I’m hosting this site on my existing Dreamhost shared hosting (and I have to say, of the few hosts I’ve used Dreamhost does seem to be one of the most feature-rich out of the box), and I simply rsync my site using the built in rake tasks that Octopress comes with. In the future I’m hoping to get myself a Linode, (primarily so that I can have access to my own remote git repositories without having to pay for a specialist service such as github) and I plan to move all the sites I currently host over there as well. At that point I guess I’ll look at changing the way I deploy updates to the site, but this method seems to work so unless deploying it via git offers any real advantages, I don’t see why I’d change.
The basic workflow in terms of creating content with Octopress is something like the following:
rake new_post["Post Title"] (Posts are all written in a markdown format, with the sources are stored seperately from the live site)rake generate (Strictly speaking you don’t have to generate the html for the whole site each time, but for now it’s the simplest method for me and whilst I only have a couple of posts, the time taken is hardly a problem)rake deployBecause the site is static and generated from markdown sources before being deployed it allows you to get a complete preview of the site on your local machine before revealing your critical typo to the world. Octopress does include it’s own webserver specifically for previewing the site on, but as much out of habit as anything else I created a new MAMP host and use that. I also like the fact that all the sources are stored locally on my laptop, leaving me free to back them up with my other documents, and also write whilst I’m offline.
One disadvantage that I see is the inellegance of including an image in a post. Essentially hosting images becomes a seperate task to including them in a blog post, so I think I’m going to cobble together a simple helper tool that can at least generate me the url of an image I want to upload even if I’m not currently able to upload it (because I’m on a train, for example). For the most part I intend to keep my photos somewhere else, but a blog post about photography is going to be rather dry without any images, isn’t it! I’m sure I’ll be able to work something out!
]]>