OnePage: a new beginning

home

Creating a startup is hard, really hard, and it has been for us here at OnePage. Quite a lot of twists and turns have occurred since we launched and even since our last post. The only thing that has not changed is our determination to see OnePage become a success. We actually had to make a lot of changes under the hood which is why it seemed we had abandoned the site. We will explain all the “behind the scenes” stories and causes for delay on a later date. For now this post is about the changes that have been made to the OnePage product.

The reoccurring feedback (aside bugs) we received since our initial release was that our product was not well defined: it seemed we could be anything or everything, thereby being nothing. Someone actually thought we wanted to create something like Tweetdeck!  Our vagueness limited the amount of useful feedback we could get since people were suggesting things in completely different directions. We take the blame for this mix up which we will throw more light on this in a subsequent post. Let us now clearly define what OnePage is supposed to be:

OnePage is a digital platform for creating, sharing and storing business/contact cards.

For OnePage to be complete, you should be able to create, share (especially with mobile phones) and store business cards. As students of the lean startup, we are focusing on the first part: create. We want to be sure you can create your card in the easiest possible way and like it enough to be willing to share it, i.e. use it as your default email signature, ‘website’ on Twitter and Facebook, etc.

One great thing about the new OnePage is that you do not need to be on many social networks to find it useful. See my card below:

Oo Nwoye's OnePage

And if you have several contact points, you will also love  and find OnePage very useful. See Joel’s card below:

Joel Gascoigne's OnePage

You may notice that we have removed several features (for now) to simplify our offering. The reason being we are not sure we know what you find useful so we have decided to put out the minimum feature set. Changes made include:

Addition:

The card is much more like a business card compared to what we had before. You can add multiple contacts of the same service (RSS, Twitter) and even label it too.

Subtraction:

The stream does not exist anymore (is that a good move?). We have also removed the various backgrounds.

Other:

The landing page has also changed to communicate what OnePage is in the shortest possible time. Is it clear enough? We also sorted a lot of the issues raised in Uservoice.

We want your OnePage to be your primary url/website, the single thing you need give people so they can then connect with you in the one million other places you exist (Skype, Twitter, email, Blog, Facebook, YouTube, LinkedIn etc). An excellent use case is your Twitter account which has only one entry field for ‘Website’; you can safely put your OnePage there and people can connect with you everywhere. Another good use is as a better alternative for your email signature. see picture below.

You may notice that we do not use Posterous for our blog anymore. It is not that we do not like Posterous (we think it is a very lovely product) but Wordpress is much more extensible and better suited for what we envisage out company blog to be like. We want to use this blog to talk about our product and more importantly document our journey launching our startup. Our role model blog is the 37Signals blog. We believe that if we teach what we are learning, we will learn and benefit more. I hope you visit more frequently (you can subscribe to our RSS feed, Fan us on Facebook or Follow us on Twitter). Thank you for all your support. Welcome to the journey!

Please let us know what you think.

What has been up at OnePage?

A lot of people have been asking that question since it seems no activity has been taking place on the site. We really appreciate your concern therefore we have decided to update you on what we have been up to. One of the challenges we have had was making people understand the primary function of OnePage. This confusion was brought about since it looked like it could do quite a number of things. This might have been because we follow the lean startup here which suggests you put out the minimum viable product. The risk of that means you might have your customer requests deviate from what your product is supposed to be since the minimum viable product might not be self explanatory enough. Therefore we have decided be much clearer when we do our next iteration.

Our plan for OnePage is to change the way we network by revolutionizing the contact/ business card, we decided to take important steps therefore we are taking the following steps in our new iteration

Standardization: If you read the last post on semantic markup by our wonderful Chief Designer Laura, you would realize the importance of interoperability and seamless integration with various standards of the web and mobile

Scalability: Since we are certain that with your help OnePage will grow, OnePage CTO Joel has taken some steps to ensure that the architecture of OnePage will be allergic to fail whales. The refactoring of some of the code has meant that we had to slow down a bit.

Structure: At the moment, we work on OnePage part time so we can pay the bills, which meant that we have to be conscious in managing our growth. We have had lots of wonderful requests from you our users and we want to ensure the time between working on an issue you have raised is done in the barest minimum time therefore we have undergone some behind the scene restructuring.

All we want to do is just to let you know we are listening and we really appreciate the support you are giving us. Please keep flooding the feedback with your awesome suggestions. We will soon (really soonJ) be bringing out a new version and what OnePage is about will be clear in 4 seconds, Deal?

OnePage, semantic markup and accessibility

by Laura Kalbag

Joel asked me to write a blog post about why we want to do things properly for our next big release at OnePage. What I mean by “do things properly” is write our markup and code like we give a damn about our users, using clean, semantic markup and accessible methods so that we can really be a truly useful service for any and every possible user.

Why

At the moment, OnePage isn’t perfect. During initial development of a web application, you’re in a big hurry to get your ideas down and working. I didn’t even turn up with my lofty ideas til around beta launch anyway. Whilst Joel and Dan had done a great job with a lot of the points I’m going to touch on in this post, we’ve decided to go for a fresh start for our next big release for a few reasons:

  1. It’ll make it much quicker to add new functions in the future (or rapid development, if you will.) The markup and code will be clean, we just need to slot in our extra functions, any extra styles if necessary, and we’ll be good to go. Right now, we have a CSS style sheet that’s got more repetition and class names than anything I’ve ever seen, any changes requires wading through CSS soup.
  2. It’ll make the application much faster. It’s not bad now, but if we can trim our code into modular blocks, our CSS into a neat, non-repetitive sheet, and minimise on the images, let alone all the clever server and PHP stuff I don’t understand, we’re going to have a quick little app rather than a Facebookesque lurching monster.
  3. It’ll be easier to test and fix bugs. If we’re not battling the monster every time we have an issue, pinpointing the layout glitch or typo will be simple.

Internet Explorer 6

We’re going to support Internet Explorer 6, which makes us akin to the nerdy prefects of the web development world. Everybody wants to give up IE6. It’s old and doesn’t behave in a reliable or predictable way. It’s a total pain to make designs and funky functions work in IE6. But loads of people use it. And we don’t think it’s their fault.

Why should these users suffer just because they don’t know any better? There’s many different reasons why you might use IE6, but I don’t think “to spite web developers” is one of them, so why should we spite them in return? It’s as simple as that!

Unobtrusive Javascript and Progressively-enhanced CSS

In a similar way, we’ll be using unobtrusive Javascript and progress-enhancement methods for applying our CSS. We don’t want to leave some browsers and users out in the cold, so we’re making sure that our application works without javascript enabled, which is a real biggy for mobile access. We want to use fancy CSS, who wouldn’t want the latest trendy rounded corners and transparency?! Instead of making something that wouldn’t work, and as a result look ugly, in the older browsers, we’ll only use those techniques in the browsers that can do it, and keep it clean and simple for the rest.

Clean, semantically-juicy HTML

We’re also going to have mega-clean, handwritten, semantically-juicy HTML, from the beginning. It’s a terrible shame that so many web applications out there has badly-written HTML. HTML is the foundation that screenreaders use to understand web sites and applications and if it’s not clear and well-structured, somebody using a screenreader is going to leave the app pretty sharpish.

This is a really high percentage of users, one we definitely can’t ignore, and not just those that are blind. Twice this year I’ve been lucky enough to experience a talk by Robin Christopherson of AbilityNet where he’s shown what it’s like to experience a site using a screenreader. It’s pretty shocking stuff and if that doesn’t convince you of the importance of clean HTML, nothing will.

Not only that, but mobile devices will have an easier time of using OnePage. If we’ve written awesome xHTML that doesn’t rely on CSS or Javascript to make sense, then the simplest of the mobile browser should be able to have a stab at understanding the pages. And mobile is only going to get bigger!

Semantic HTML, using all the optimum and most-descriptive HTML elements when we’re writing our markup, helps in many different ways. For a start, it helps other systems understand our web pages:

It helps users understand and read our content more easily if we use lists when we’ve got a list of items, quotes when we’re quoting somebody else and headings to describe our content. You wouldn’t put <div> tags around a link and expect a user to copy and paste it into their address bar, so why wouldn’t you use the other appropriate HTML tags?

It helps Google understand what the focus of our page is about when we use appropriate and descriptive headings.

It makes writing CSS a hell of a lot easier. If everything is made of <div> tags, then we’re going to have to give every <div> a unique and descriptive id name. If we have well-structured HTML with a variety of tags, we might even be able to do away with id and classes altogether, and wouldn’t that make it easier to trace the cause of that CSS bug?!

We can even make our pages *even more* semantic using super-juicy awesomeness like Microformats. We already use microformats for vCards, so that another application (either desktop or web-based) can pick out our users’ contact details easily from OnePage without any copy-and-pasting effort on a user’s behalf. This will make OnePage tastier for Google, as it can use microformats to find even more relevant search results for its users, and other applications can use them to share the data from OnePage, potentially promoting a wider awareness of our app.

So

I hope that’s an interesting little insight. I’ve tried to touch on everything without going into mad detail. I hope it hasn’t left anyone screaming and running away or thinking I’m a masochistic individual. If anybody wants to discuss any of this stuff further Joel and me (Laura) are always up for talking about this kind of stuff. Any recommendations or warnings are also appreciated. We’d love to hear if anybody else has put this much effort into their web app!

OnePage wins 3rd place for Social Networking at Webstock Awards 2009

We’re delighted to let you all know that OnePage was awarded 3rd place for the Social Networking category of the Webstock awards in Bucharest on Friday! It came as quite a surprise to us, and we feel we have plenty to do yet before we deserve to win awards such as this, but it does give us a little reward for the hard work we’ve put in so far and gives us great motivation to keep doing what we’re doing.

I’d like to thank all of you for your support so far. It’s you early adopters who are really going to shape OnePage to become a useful application. We still have a long way to go and be assured we have received your suggestions and are very thankful for them!

Integrating Tarzan Amazon Web Services PHP Toolkit as a CodeIgniter Library

At OnePage, we are building our startup based on agility using lean startup techniques and customer development. Some of our influencers are Steve Blank, Eric Ries and Timothy Fitz.

Into this goal comes Amazon Web Services, which enables us to do without the need of a sysadmin, saving costs and improving speeding time to deployment. It also helps us with scalability and flexibility.
The great thing about right now is that there are so many great people out there coding things and making them open source. So when we chose to make use of Amazon Web Services, it did not take us long to find the fantastic Tarzan Amazon Web Services PHP Toolkit (which I think will soon be renamed to CloudFusion). This toolkit makes using the AWS API for S3 and SimpleDB amongst other services much easier.
In addition to making use of Amazon Web Services to leverage cloud computing, we also use CodeIgniter as our PHP Framework as choice. I won’t get into the debate of why we do and why we chose it over other frameworks, as that is a topic for another post, but I’ll go with their description: it “helps you write kick-ass PHP programs”.
Today I came across a post in the Tarzan Google Group where someone was asking how the Tarzaon toolkit can be integrated as a CodeIgniter library. We’ve done this at OnePage so I thought I’d share. Credit for this goes to Dan, our lead developer :)
It’s quite simple really:
  1. First, put the contents of Tarzan in a directory titled “tarzan” in your Application Libraries directory in CodeIgniter.
  2. Add the required constants from the config-sample.inc.php file in tarzan to the CodeIgniter config/constants.php file to set up your AWS Access Identifiers.
  3. Write a CodeIgniter Library to utilise the Tarzan toolkit which you now have placed in the libraries directory.
  4. Use Tarzan AWS Toolkit as you would normally.
Code sample for step 3 (File named “Aws.php” placed in application/libraries):

if (!defined('BASEPATH')) {exit('No direct script access allowed');}

class AWS
{
function __construct($class = NULL)
{
ini_set('include_path', ini_get('include_path').';'.PATH_SEPARATOR . APPPATH . 'libraries/tarzan');
require_once('tarzan.class.php');
}
}

Code sample for Step 4:

$this->load->library("aws");

$sdb = new AmazonSDB();
$del = $sdb->delete_attributes("your_domain", $itemName);
$success = ($del->isOk());

I hope that helps someone!
If you find our posts useful check out our OnePage and keep up with us on Twitter and Facebook. As always, we’d love your comments!

Permalink

| Leave a comment

We have launched OnePage!

Welcome to OnePage! Thank you very much for your patience. We have been as excited as you in waiting for the launch. You may have noticed that the domain now reads myOnePage.com. It was a tough choice choosing the name OnePage and getting the appropriate domain address available. getOnePage.com was a good address but we think myOnePage.com is much better as it reflects the personal nature of your OnePage.

OnePage grew from Joel’s laziness to update his blog; he wanted to pull together all his activities on the web without having to do anything extra. It has grown much more since then, and we plan to revolutionize the way contacts are shared in the world. We have gradually started rolling out the invites to those that have signed up for the beta. If you have signed up and eager to use OnePage, shoot us a tweet or an email, better still…call me +447552501471 We are also trying hard to ensure it works well with internet explorer (phew!), but for now, we recommend you use Chrome, Firefox, or Safari to get the best experience.

The success of OnePage is wholly dependent on you the users as this is a private beta and we have loads of work to do. Your feedback and suggestions would be very invaluable to us as we try to develop what you want. Please inform us of any bugs you might come across. So hurry now and get that username you deserve before someone gets hold of it!

The Countdown has begun!

We are as tired as you in waiting for OnePage to launch! Therefore we have now committed ourselves to countdown. No more “we are launching soon”. In less than 2 weeks, we would have remove most of the nasty bugs to make OnePage a pleasurable experience! I hope you like our new homepage. Thanks for your patience and support !

Let us reveal a little more about OnePage!

Hello friends!

We’d like to put out this short video to give you more of an idea of what OnePage will do for you. This is the first time we’re revealing OnePage to everyone so check it out:
OnePage is the one place someone can go to in order to find out everything you’re doing on the web :)
Thanks for the continued support from all of you!

Talking With Scobleizer about OnePage

Hey OnePagers!

Something exiting happened on Sunday! I met with the TravelingGeeks and they were impressed with OnePage! I got the opportunity to do a little interview with Scobleizer.

PS: While I was wining and dining with the TravelingGeeks, Joel and Dan were working hard to get OnePage ready for you!

OnePage: Organising Your Social Streams.

Hi

Thank you for supporting OnePage! A lot of you have been asking for more details about what OnePage is , so we decided to make this video for you! We are very grateful for your patience but we assure you that it will be worth it. You can share this post and video with your friends. If you haven’t registered for OnePage, you can do it HERE.

Thanks!

Team OnePage