Well, Notipal makes landing page email collection really easy. If you have the technical ability to install Google Analytics on a HTML page (copy & paste), Notipal will be a walk in the park for you; there’s just three steps involved in getting Notipal collection emails from on your landing page (for free):

1. Sign-up by entering your Website URL & email

2. Copy & paste the Notipal code

3. Verify ownership & activate your account

That’s it - you’re now collecting emails and will soon be receiving handy email reminders with stats on the number of subscribers.

“But I thought Notipal was just for error pages(?)”. This use case ties in with the core Notipal proposition; your Web service isn’t available, and Notipal steps in to collect contact details in aid of a follow-up, once-off notification to all the people who have been kept waiting. Landing-page subscribers don’t want to be locked in to a regular newsletter at this point - your product launch is a once-off notification (the default behavior of the Notipal notification system), and that’s the only email message these subscribers are expecting.

I was desperately searching for this feature back when I first started tinkering with websites on a DreamHost account - but I couldn’t find anything. Now I know Notipal does what I was looking for, it’s something that I can see myself using again & again. Will you be using Notipal for your next pre-launch landing page?

The move from Engine Yard to SliceHost was a tricky one, partly because of the number of dependencies that SoIndustry relies upon (background processes, search indices, daemons, multiple cron jobs, etc) and partly due to my lack of Rails deployment knowledge. Rails deployment isn’t quite as simple as it is with Wordpress, for example.

Capitalizing on this opportunity, Engine Yard offer a service which takes responsibility for the Rails deployment set-up & ongoing maintenance of dependencies (such as the Rails framework and associated Ruby gems), but SliceHost are a completely hands-off DIY VPS hosting option (you configure your OS, Rails gems, etc). However, the price difference between the two is huge ($399 vs $38 in SoIndustry’s case) - and, thanks to past experiences, I’m now a believer in web businesses taking a little time to understand their production environment in the early stages, and saving a ton of cash on the hosting costs, by ‘optimising for now’ and going with a cheaper self-managed hosting option, rather than one of the all inclusive completely-managed Rails hosting options. Managing your own server slice can sound frightening, but let’s put it this way - if you’ve managed to put together a development environment on your Mac or laptop, the production environment isn’t drastically different. And if you’re lucky enough to have a friend who can help out when you get stuck (Ryan Townsend has helped me out on tons of occasions - thank you Ryan!), or an IRC client connected to #rubyonrails - there’s always someone you can turn to for advice.

While SoIndustry is still in private beta right now, it’ll soon be opening up to the wider Web, giving you an opportunity to share your industry insights & knowledge in combination with a sharply presented profile and resume (but there’s more to come on those, too). However, I’m really eager to hear your thoughts on SoIndustry as it is right now, especially if you’re a Twitter user; have you had any thoughts on the direction of SoIndustry? Are there any features that would make it a must-have product for you? Leave a comment here or post an update from your SoIndustry profile.

Copy/paste a line of code in to your error page template, and when your site throws an error page, you’re notified immediately, and your visitors get the option of leaving their email address for a follow-up notification when errors (those they specifically encountered) have been fixed. You could look at Notipal as an administration interface that wraps-up the all errors that occur on your website and creates a communication channel for keeping in touch with the visitors inconvenienced by each error.

You can try it for free, and it’s very easy to install (as easy as Google Analytics):

The service has been up in testing among web industry friends & contacts, and it’s time to reach out a little further and to have Notipal catching, collecting, and making errors a little less painful on your website and - if you’re a professional designer/developer/agency - your clients websites, too:

How did the idea come about? My Dad was trying to get on his online banking, and I was observing the process. But here’s the rub; the site was throwing a 500 error, “Internal Server Error”, on an un-styled error page.

After numerous cycles through the ‘right-click / refresh’ process in an attempt to access the site, I declared this to be tedious. Why wasn’t the page styled with corporate colours and logos, and why wasn’t there a form that read, “Enter your email address and we’ll notify you when we’ve fixed the problem”? That’s where the idea for Notipal came from - a pain point as a website visitor who just wanted to be told when something was fixed, rather than being left in the lurch to “Please try again later” (Thanks. When?).

But Notipal isn’t just for 500 pages - it can help with broken links, too. Let’s say you’re running an ecommerce store with a broken link which should be pointing to a product page; with Notipal installed, you’ll find out about the “Page Not Found” and get a chance to bring the potential customers back, direct them to the correct product page, and avoid losing the sale to a competitor.

Actually, there’s many more Notipal use-cases planned for development on the product roadmap.

Notipal is a Ruby on Rails app. It uses Shoulda for testing, Starling/Workling for asnyc processes, daemons for repetitive background jobs, and MySQL for the DB. It’s hosted on SliceHost (I’m really happy with these guys - they’re a great, low cost alternative to some of the more service-orientated Rails specific hosts). On that note; SoIndustry is using Notipal whilst it’s being transitioned to SliceHost (it’ll be back soon with lots of improvements).

I’m all ears for your thoughts & suggestions; is Notipal something that you’ll be installing on your website?

Firstly, the process of replying to someone else’s status update has been improved - threaded reply submissions are gone. You can still view all replies to a status as a thread (which you can’t do on Twitter, just yet), however, replies are now posted/submitted as @replies (just as they are on Twitter) through the main ‘What Are You Working On?’ boxes on your Dashboard and in your Newsfeeds (which are now known as Channels, but more on that later). This means that you no longer lose sight of a reply as it is posted (as you used to when they were tucked away from timelines and threaded underneath the status update being replied to). Instead, replies are now recorded in the timeline and treated as first class citizens alongside statuses, just as they should be.

@replies also work much better for SoIndustry Channels (previously known as Newsfeeds). Instead of tucking away replies every time they are posted, Channel timelines are now populated with the entire flow of the conversation, rather than a broken down per-topic, disjointed approach. This may sound like a information architecture nightmare, but for the short-form-factor of micro-blogging/status updating, @replies create a much better user experience; the conversation seems to flow more easily because it can be followed by scanning a page, rather than clicking from URL to URL or backtracking to an older thread.

SoIndustry | @replies are here!

Secondly, Newsfeeds have been renamed to Channels. There was, and still is, a good reason for calling what is essentially a group, a Newsfeed (the product roadmap would explain all) - but in the process, the Newsfeed naming convention confused people.

I wanted Newsfeeds to be used as either a chat/discussion channel, a social RSS news reader, or a combo of the two - but their best use case has always been as an easily accessible chat room. Therefore, the ‘Channel’ naming convention, like on IRC, started to feel far more appropriate than ‘Newsfeed’, as the later seemed to convey that they should only be used for news aggregation (as I learnt from watching their usage). Along with @replies and the subsequently improved chatting experience, the Channel naming convention had to come in to play. So, if you’ve ever wanted your very own Twitter like groups but in a clean interface with easy navigation between all your groups, and a Dashboard to pull all these separate groups together , the new SoIndustry Channels should do the trick.

RSS aggregation is still available within Channels (in case you want automated posting of information from other sites) but with SoIndustry version 2 you no longer lose comments from your blog posts because commenting on news items is now only available through Updates in the timeline; SoIndustry enourages users to post comments as part of the Channel conversation, rather than as a threaded comment which really belongs on the original URL, be it a blog post or article on a newspaper site.

I’ve had tons of ideas for Channels that I want to set-up, one being a Ruby/Rails/Web technology group for Warwickshire (it’s hard to find people!), and another being a YCombinator Hacker News Channel (to compliment the news orientated discussion in the forum). Let me know if you want to join either of those. Or, perhaps you have an idea for starting your own Channel, e.g. how does a ‘Design’ channel sponsored by your design consultancy company, and with your company’s banner advertised alongside, sound to you?

SoIndustry | Newsfeeds are gone, Channels are here.

Thirdly, and finally, the interface has been spruced up, at least from a information architecture perspective. Most notably, your joined Newsfeeds/Channels (they are now known as the later - hopefully I’ve made that clear by now) are now accessible in a consistent ’side tabs’ area on the right hand side of the interface. The Tabs enable you to quickly skip between all the Channels you’ve joined, post updates within them, check on the news, etc (all the stuff that makes your SoIndustry experience customised to you) but with only one click between each of your Channels. Of course, you can easily choose which of your Channels should be displayed in your side bar (it’s a checkbox within the respective Channel’s ‘options’ tab).

SoIndustry | The redesign

That’s about it for Version 2. Initial feedback seems to be positive, e.g. a couple of people have said they love the new interface. But what do you think? I’m open to all criticism, so please let me know in the comments. And if you haven’t signed-up yet, what are you waiting for? Start a channel and share it with some contacts.

ThinkRefresh was founded by Ryan Townsend, a veteran Ruby on Rails coder and Internet Computing undergraduate at The University of Manchester. Ryan and I met on a Rails community site and have been collaborating on projects since then (most notably, he helped me learn the ropes for Rspec, the Ruby-based test suite framework that should prevent bugs from creeping in to http://SoIndustry.com). We also have a Web application project in the works over at http://Notipal.com. It’s a service that will help with Web service downtime and outages, i.e. if SoIndustry was to Fail Whale, Notipal would help in more ways than one (and we’ll detail them all, soon enough). My commitments to SoIndustry, and Ryan’s University work & outside programming employment, mean Notipal isn’t going quite as quickly as we would both like - but it’s definitely getting there.

The article, “Personal Projects: Keep Them Simple”, briefly looks at how you can choose an appropriate idea for a personal project (or start-up) with a goal of keeping your idea very simple & focused - which, I believe, significantly increases your chances of success. Complexity and a lack of consistent vision can easily cause projects to flounder, and that’s something we all want to avoid.

Aside from the fact that simple ideas sound great to other people, there’s a second, albeit no less important benefit for building an application which solves a problem – it’s much easier to say ‘no’ to anything but the core feature set required to solve the problem you’ve diagnosed. This point is particularly topical for ThinkRefresh readers; along with naming things and cache invalidation, feature creep is a programmers worst enemy…

[ Read the full article ]

In SoIndustry, people post status updates, other people reply to them. There are two obvious routes[1] for enabling this interaction in a Web-based user interface;

1) Threaded replies: I click ‘Reply’, a form pops in to view, and I can post my reply underneath the status update. This is how SoIndustry works (among a handful of other status update orientated apps).

SoIndustry | Posting a reply underneath a status update

SoIndustry | All replies threaded underneath the status update

2) @replies: I click ‘Reply’, my mouse cursor is focused on the form through which the status update was posted, and I post my reply there. This is how Twitter works.

Twitter and @replies

And here are just a handful of the user-interface implications you now need to consider, based on your choice of Threaded-reply, or @replies, for your ‘reply system’ implementation;

• With threaded-replies, my reply is tucked underneath the status update, and may - or may not - be published at the top of the timeline. With @replies, I wouldn’t expect anything less than to have my reply published at the top of the timeline (otherwise, where is it going?).
• Threaded-replies create hierarchy between status updates and replies, @replies don’t.
• Threaded-replies let people track all replies to a status update (they’re aggregated underneath in the form of a thread), @replies don’t (if you want to know why they don’t, try implementing threaded @replies in your own application, or ask the creator of Quotably).
• Threaded-replies make it easy to implement ‘group’ permissions, because status updates and replies can be assigned differing levels of authority (e.g. I, as an ‘Admin’ can post a status update in my group timeline - you, as a lowly ‘Member’, can’t - but perhaps you’re authorised to post a threaded reply underneath any status updates in the group). @replies don’t, because people are always expecting to see a form through which they can post an @reply, and the @reply should always go to the top of the timeline, rather than being aggregated underneath a status update.
• Threaded-replies steer you towards keeping replies out of timelines altogether (otherwise you’re posting replies underneath a status update and then watching the same reply up at the top of a timeline, too), making it less likely that people can continue to follow a thread (as the status update is pushed further down the timeline), unless sufficient email notification options are implemented. @replies always bring the latest content to the top of the timeline, be it a status update or a reply.

Confused yet?

If not, do you have a preference of a threaded-replies or @replies convention? Or have you and navigated a similar blue-pill/red-pill path in your own start-up endeavors?

[1] I’m working on the third, and it’s brain-frazzlingly complex from a UI perspective.

1. Expect Broken Features

You’ve worked hard on getting your Web application to a state in which you’re ready to share it industry contacts, friends, or even family (and hopefully it didn’t take too long to get to this point). But even if you have the most comprehensive test suite ever conceived (presuming you’re working with a development framework/environment which encourages testing, e.g. Ruby on Rails, in TDD or BDD styles), things are going to break, and it’s very annoying when they do. Despite this only being a private beta, you’ll want to impress anyone & everyone who comes across your product, and broken features have direct effect on first impressions.

As soon as outsiders start using the application, bugs will crop up - literally, straight away. Some will be complete show-stoppers (the RSS parser has broken in SoIndustry a few times, and RSS aggregation is an important part of the service; even the registration form had a bug at one point), and when those big issues do show up, you need to be ready to tackle them and work through them asap. They’ll often ruin your plans for the day.

The plus side to all this is that you’ll quickly learn what really needs doing, and in what order. When you’re in pre-beta development, it’s easy to spend too much time focused on things that really don’t matter that much (color:#AAA; or color:#BBB;?). Get in to production and you’ll almost immediately change your approach to prioritisation; nothing brings the product development cycle in to focus like having people using your product (or not, thanks mr broken registration form).

2. Have Community Ready to Go

During the development period of your product, hopefully you’ve created some kind of audience ready to receive it and to use it. You don’t want to launch a private beta and to have absolutely nobody willing to use it and run through the user experience in the unstable first release (I’d like to think that this is slightly different to ‘having a market for your product’).

SoIndustry has been a long time in the making, and during this time I could have done more to build up the subscriber base for the couple of blogs I’ve set-up over the last year or two. The good news is that people have been in touch with me during development, a few people have subscribed to the blogs, and they’ve all been happy to go straight in to the site to help with the bug testing and preparation for a public launch (no ETA yet). If you’re one of those people, thank you - it has helped a lot.

Running a blog can be a full-time occupation (running a blog about blogging can be a full-time occupation), so you don’t want to focus on building a blog community the detriment of your Web application development (your app is your product, not your blog posts). But it would be more than sensible to gather email addresses and subscribers on a pre-launch teaser blog, and to have people ready to go in and scrutinize your private beta offering as soon as it’s live.

3. Provide Instructions

The private beta is where you’ll really find out whether or not your app cuts the mustard on the usability front. Usability is hard, but the closer the tie between your front-end team and back-end team, the more usable your product will be (that’s a topic for a follow-up post).

No matter how much you’ve done to make your application usable before a private launch, people will still be confused by things, they’ll feel lost at times, and they’ll be very tempted to give up after the registration form returns the first validation error on the email address they entered without an @ symbol. This is where clean and clear on-screen prompts (but not too many, mind) are vital, even on your form error messages. Site tours upon first log-in, tips sprinkled around in obvious places, and an up-to-date FAQ, will really make a world of difference to the user experience in your application. If people in the private beta aren’t using the application in the right way, you won’t be using the private beta to learn what needs correcting for the public beta (and that’s why you’re doing a private beta in the first place).

SoIndustry probably doesn’t employ enough instructional features, but it’s a simple application to use and navigate (so I’ve been told, please tell me if you think otherwise, and if you haven’t signed-up, please do so - show off your expertise, post an update, upload a banner for your professional services or company, check out the Newsfeeds…). Because SoIndustry is built around status updates, if something goes wrong, people have a tendency to just post a status update explaining the problem. That makes my life easier.

4. Set-up Feedback Channels

As previously mentioned, I’m very lucky regarding SoIndustry feedback; people can just post a status update when they find something that doesn’t work as expected, e.g. “I can’t access the People tab in my Industry” (that actually happened). I love this (the ease of use, not the broken features) - there’s very few barriers to entry for someone willing to share their annoyance with a broken feature (that’s as long as the status update feature isn’t broken, then it’s game over).

If you’re not building an application through which people can post status updates, you’re going to need another route for collecting feedback. Email is an obvious choice. Ask people to email you right back when they’ve been in the application and had a good look round. But be realistic and only setup feedback tools which you’ll definitely use. For example, Uservoice channels look like fun, but you need to make them well integrated (i.e. use the widget they provide) otherwise people won’t use them.

5. Make Architectural Changes & Move On

Code goes stale, features become deprecated, design becomes outdated, and you’ll never be 100% happy with your product. Always bear that in mind, Optimize for now!, say 37Signals. However, post-private beta launch, you’ll probably start mulling over some big architectural decisions which you weren’t 100% decided on prior to the private beta launch. You’ll be tempted to make those changes now because they’re the ones you won’t be able to forgive yourself for in a public launch. If you really have to make these changes, make them asap - just do it, and don’t think too long & hard about it. Having less options makes you happier. Be honest with yourself and immediately make the changes which are currently occupying 80% of your brainpower.

That’s it; those are my top five. Do you have any tips for a private beta launch?

Why SoIndustry.com? I’ve been monitoring the market[1] for quite some time (check the WebApproriate blog for proof) and SoIndustry has an opportunity, through its positioning, packaging, and initial feature set, to answer my concerns with what does (or doesn’t) exist in other Web applications & services. How? It’s probably best if you sign-up to SoIndustry, I’ll activate your account asap, and you can test out the site - but here’s a brief explanation: You get a professional/industry orientated profile alongside cleanly presented status updates, replies & conversation (which are easy to follow), and commentary on news (and the news itself). You join an industry network which quickly slices through SoIndustry to the content that matters to you (as we build up the userbase, that is - it’s early days). If that wasn’t enough, SoIndustry also allows you to start your own channels for content (group-specific status updates combined with automated RSS aggregation) in the form of ‘Newsfeeds’, which can be shared in the same way that ‘Groups’ are, in other services.

As a beta prototype, SoIndustry is already a lot of fun to use (experienced Web designer/developer friends are telling me the interface feels very polished and that the site is very easy to navigate), it gives you tools and branding opportunities you can’t find anywhere else on the Web (check out @Ryan and @JonMoss and their profile banners), it’s far from perfect, but there are big plans for improvement, and I am definitely going to enjoy working on it more than any other Web application out there right now - I can’t wait to iterate on the feature set.

As for the development process and the logistics of designing and developing a web application on your own (not advisable); getting to grips with Ruby on Rails, and Web development/programming in general, has been challenging. But now that I’ve come some way towards an understanding of how to get from an idea to a working Web application, the product development process is becoming enjoyable. From now on you can expect blog posts on the topic ‘building a Web startup’ to be published here, so if you’re interested in finding out more about how I went from an idea to SoIndustry.com, subscribe to this blog’s RSS feed or sign-up to SoIndustry.com, I’ll be posting updates from my SoIndustry profile, too. It won’t be all about the technology, either. I’ve had numerous meetings on the business-end of the product (incorporation, T&Cs consultations with the professionals, even had a term sheet on the table, at one point) and we’ll cover those, too.

Finally, check out SoIndustry.com and sign-up for a beta account (grab your preferred username identity, several first-names are still available), and leave a comment here for the VIP treatment and to have your account activated asap. And once you’re on the inside, you can send beta invitations to friends/contacts interested in promoting their professional services and keeping in touch with their industry.

[1] The handful of socially-orientated web applications that we hear about the most, i.e. Facebook, LinkedIn, Twitter & Jaiku.

Well now there’s a clear ‘best practice’ solution, all thanks to the clever people in Japan (and Cabel Maxfield Sasser for highlighting this international trend to people stranded in Stratford-Upon-Shakespeare): Don’t hand out URLs, hand out search terms. Despite being a navigational technique afforded by the Google robots, this really is the most humane way of directing someone to a site:

Paying for SEO services from an SEO consultant will generally get you what you want: higher, relevant ranking in popular search engines. But the majority of what SEO delivers is just best practices. After that, there remains search-engine specific tricks and link-building strategies.

Although I wouldn’t quite take the hardline that Eoghan has in the rest of his posts; in 2008, SEO really does just feel like best practices, not the one-stop-shop for taking your fair share of Internet traffic that it was years gone by.

Being the un-cool Web fanatic that I am, I’m often quizzed about SEO by friends, family, and contacts. But being a social networking, blogging, discussion forum focused Web fanatic (with very little traditional SEO expertise whatsoever), I tell them not to worry about SEO, and that keeping a site’s content semantically structured (a.k.a properly coded with h1s, h2s, CSS for styling, etc) as a base guideline, and fresh and compelling above and beyond that guideline, is far more important than condensing keywords into a welcome page. A news/blog/discussion area, or at least some kind of CMS (content management system), should be considered as a means of regularly publishing more of your clean, well-structured data.

Unfortunately, many people still look at SEO as the implement with which to take a once-off stab at getting a website right (or at least until the next web consultancy comes in for another complete makeover), and that the keyword ratio will work the traffic-magic until the next re-branding. By taking this approach, you’re just creating a static site with contrived copy, not a site which gives people a reason to visit time and time again.

Above all else, focusing on SEO promotes the wrong mindset for website owners. Websites need to evolve, they can’t be built and left to do their job on their own, no matter how many keywords you fit in a three-hundred word paragraph after the Flash intro video (not so good). Everyday you’re writing pitches, proposals, newsletters, press-releases, job ads, marketing campaigns, and sending them all through the email silo. Find a way to keep these resources flowing through your website too, and make sure your have the infrastructure in place to make this a quick, painless process.