News.YC readers: After receiving feedback on my original post, I decided to delete that posting and to rewrite it, with some more insight into less of what I did and rather why.

After being somewhat burned out of my Avecora OnDemand project (because my CSS and Javascript were throwing fits in Internet Explorer) (yes, this is the cause of my burnout) and after seeing a few “how I built a webapp with just $x,000 and x people” I decided to go ahead and build something I’ve been thinking about for a while.

Thus SpeakHQ was born. SpeakHQ is a service that lets you take the micro-update/micro-blogging idea that is embedded within Twitter, for your group. This was originally developed for Avecora OnDemand, however I wanted to make it free to use for all, and with some other features like joining multiple groups.

Just to clarify, this doesn’t use the Twitter API (or else I’d have to deal with it going down every 10 minutes, hitting 70-requests-per-hour limits with 35 requests, etc.) and it’s built from scratch.

Team:

  • Mark Bao, developer, designer, everything else
Timeframe:
  • July 3rd: 10am – 12am EDT.
  • July 4th: 10am – 2pm.
Why it’s useful:
  • Communication with micro-updates forces people to be concise and not go into large amounts of detail, one of the problems that plagues email (and skimming email)
  • Twitter demonstrated this – small updates are easy to digest. If they didn’t have a 140 character limit, Twitter would be nothing but a simplified weblog community.
  • Groups with Twitter is hard to do – the easiest way I’ve seen to do this is distributed direct messages. Although it leverages the user database of Twitter, it doesn’t present a clean solution.
  • Keep track of your own private groups with groups or projects, with co-workers, friends, or other group members, as well as public discussion groups with public groups through the group finder.
How it went down:
  1. July 3rd. 10am EDT: I used a PHP MVC framework I wrote a few months back called ActiveVC. Doesn’t have anything to do with venture capitalists, though it is a MVC framework without the Model; essentially it is a simple template engine. (See Decisions Made below for more information.) I might release it sometime for the hell of it. Decided to use moo.ajax with prototype.lite.js at first, but decided that jQuery would be better for more useful Ajax calls as well as the rest of its set of features in CSS manipulation, etc. Started database schema and planned out the UI.
  2. 12pm: User account system ready, session data is able to be handled. Working on the basic user-group membership association, and loading groups and posting messages via Ajax.
  3. 3pm: decided on the name speakhq (it was either that or groupchan) and registered the domain. Cost: $6.99
  4. 4pm: new group, group settings, user settings… and preview testing with some friends.
  5. 5pm: refreshed the interface, looks a little less bad now.
  6. 7pm: groups directory. joining/leaving.
  7. 9pm: new account creation, email invitations to public and private groups.
  8. 11pm: data sanitization (should have thought of it first) using a php function called __() (two underscores) that instead of using echo $var I use __($var) and it echos sanitized output.
  9. 12pm: bugfixing and then sleep.
  10. July 4th. 10am EDT: checking on domain registration (T_T) and then fixing miscellaneous bugs and stuff.
  11. 12pm: opening VMware to test in IE6 and IE7. OH MY GOD IT IS SO BROKEN
  12. 12:30pm: half an hour wasted fixing IE problems with PNGs, margins, random stupid width problems, etc. Thank you stilleye guy for IEmarginsFix.js, and to whoever came up with the underscore hack.
  13. 1pm: uploading to server, changing database stuff, and it’s released. yay!
Decisions made:
  • PHP MVC framework. Although my primary PHP development framework is Kohana, I decided to use my ActiveVC framework as it was light and fast at processing pages – and I didn’t need all of the features and larger library of Kohana (as it would only get in the way.)
  • Usernames or emails + name? To ensure that all user accounts were universal in the application, and to reduce confusion, I decided to deviate from Twitter’s username + name model (which made things somewhat confusing) and just went with usernames.
  • Database schema. I didn’t get a chance to catch Twitter’s SQL yesterday, but decided to set it up as follows: 
    +-------------------+
| Tables_in_speakhq |
+-------------------+
| groups            |
| invites           | (table holding invite codes)
| members           |
| messages          | (these are status messages)
| users             |
+-------------------+
5 rows in set (0.00 sec)
    This makes things logical for SELECTs and JOINs, and I'm not sure how Twitter does their schema. I chose InnoDB for its better locking levels (row level lock in InnoDB vs table level lock in MyISAM.) Since I'm updating the groups table as new messages are posted, and that new messages are easily (and frequently) posted, InnoDB was the better choice for the database.
  • Public vs. private groups. I implemented the different privacy levels to easily facilitate SpeakHQ “discussion groups” on a certain topic, such as the group speakhq suggestions where users suggest improvements for the service. Based off of this, in public groups anyone that is a member of that group is allowed to invite others to the group, whereas in private groups only the group owner is allowed to invite (with a one-use randomly generated invite code that adds them automatically to the group upon registration completion.)
  • No private messages and no profiles in first release. SpeakHQ is based on group discussion and collaboration, whereas Twitter is based on individuals sharing information to a group of other individuals (followers.) I’m still looking into what kind of messaging system should be put in place – form for email, or a system like Twitter’s direct messages?
  • Lack of replies and permalinks. I will be implementing permalinks in the future, but I don’t see the value in replies in a group space – unlike Twitter, conversations aren’t between a large number of people (at least in private groups.) However, I’m going to expect that people will be asking for it, so I will implement it soon.
  • User levels. Implemented into the database (binary member or administrator) but I didn’t implement a member level editor, for the reason that it would become more confusing in terms of how much control other group owners other than the group creator had over the member list, and the group privacy level (and we’re trying to keep things simple here.) Group owners don’t usually have much control over a group, other than changing group privacy level and the name of the group (and later deleting status messages, kicking people from the group, etc.)
Still left to do:
  • forgot password / password and email changing
  • deleting status updates
  • public group viewing
  • member list for administrators to be able to edit the group members (kicking, admining?)
  • customizable group avatars, environment (background colors, etc.)
  • yes, I will be releasing an API soon
  • outgoing SMS gateway
  • new design (it really needs one)
  • incorporate some colors