CareLogger is a tool for diabetics to keep track of glucose levels, blood pressure and when they take medication.

We soft-launched about a week ago and so far 70 people have signed up which we’re really excited about.

The CareLogger Story

The idea came after me and my collaborator on this project, Nick Van Nuil from Dalmeny, discovered after speaking to a few people that there was a serious lack of tools online for diabetics. The one that came closest was an expensive windows-only application that had a very difficult to use UI.

So we spent 3 days creating a web application, with the idea of having a tool that will allow people with diabetes to track their illness from any web browser (and possibly a iPhone application in the future, if there’s demand).

The Plan

Right now we have no plans to charge money or display ads on the application. It was a great exercise in creating a minimum viable product as well as learning how to build a community and helping people manage their illness along the way.

CareLogger originally had the name HumaLogger that came from the name humalog, a name for insulin. But we decided to change it to CareLogger after finding out that humalog is trademarked.

We’d love to hear any feedback. You can try it out using our demo account (username: demo; password: demo) at http://carelogger.com/.

One of the most competitive (and seemingly profitable) industries that fits into this category is sports betting.

I ended up spending a few hours this morning checking out the various sites, search results and landing pages they used and it was interesting to see some of the most aggressive online marketers at work.

Here is a short analysis and some observations of what I found:

Landing Pages + SEM

Much like poker and mortgage sites, users are frequently in a ready-to-buy mindset and these sites employ a razor-like focus on getting the user signed up and betting as quickly as possible.

Many of these sites rely heavily on search engine marketing that direct users to sales-focused landing pages. Accord to this Adwords article, this type of advertising is only legal in certain countries.

bwin’s Landing Page

SportBet.com’s Landing Page

Betfair’s Landing Page

A few more landing pages: PaddyPower, LadBrokes, Coral and Bet365

Here is a very common themes in almost all of the SEM landing pages I came across:

• 1-2-3 Almost all of the landing pages used “1-2-3″ to sell the idea that its super-easy to signup; for example: “1 – Register, 2 – Make a Deposit, 3 – Start Betting”
• Imagery: All used imagery specific to the sport that was searched for, for example “football odds” brought me to a page with a soccer player who looks like they just won a game (I used Google UK, Google Canada has no gambling ads)
• No Sign-up Forms: Unlike mortgage/education landing pages, very few sports betting sites included signup forms on their landing page
• Call-to-actions: Instead of forms they all had giant “Join Now” call-to-action buttons linking to the forms
• Familiar Logos: All used logos that users are familiar with: major credit card logos, verisign, company partners like “FIBA”
• Engaging offer: most had an engaging offer, for example, free bonus money to start with or rewards

The average cost per click in Adwords is around $2-3, which is pretty standard for competitive keywords. Some keywords such as “sports spread betting” can cost up to $10+ a click.

Homepages

Organic search results linked to either 1) a landing page style homepage or 2) a section tailored to a specific sports.

These pages were frequently just large landing pages with the pure focus of getting the user to sign up. But some featured todays games and some articles.

Here were some commons themes among them:

• Dark designs, I was surprised by how many sites with black backgrounds I came across. It might be to mimic the appearance of the type of bar’s where you’d find sports bookies.
• On-page SEO: internal linking structures, titles, articles etc
• Imagery: a mix of happy sports players and sexy models
• Javascript Clocks: many sites had a live clock on every page, sports betters eagerly anticipate when games start and when they find out if they won or lost

The two that really stood out were SportsBooks and BoDog.

Affiliates + Content Sites

Sports betting seems to rely very heavily on affiliates to bring in traffic. The average payout among the top sites was around 25% of what the customer spends. Based on the number of spammy sites and affiliate landing pages I came across, I got the impression this is a hyper-competitive market.

One of the most common approaches by affiliates was to create content sites that followed this pattern:

1. Create a series targeted articles filled with keywords
2. Create a press release of the same content and get it index on sites like news.google.com and ezinearticles.com
3. Surround the articles with Join-now buttons for sports betting sites

For example: RedNose and CrunchSports

Conclusion

There are a few things startups in more conservative markets could learn from these hyper-sales focused sites.

Sports betting sites have the luxury of having visitors that are frequently ready to buy and each has the potential to bring in a lot of money. This means that quite a bit of marketing dollars can be spent on acquiring each customer.

But at the end of the day, I don’t want to give sports bookmakers too much credit given the addictive nature of gambling.

Losing Conversions from Indian Street Addresses

For the last few weeks at Learnhub I’ve been trying to optimize the conversion rate of our school application form. This form is lengthy compared to most and we required that potential students entered their home address.

As an experiment, we hooked up Google Analytics to track every time a validation error happened.

We were surprised to discovered that 20% of users failed to enter their street address properly and half of those users then exited the site. This was a big warning sign that our validations need improvement.

So we began to look into why this is happening in more detail.

We realized that our indian users were skipping the address not because they didn’t want to share it but because Indian addresses are really complicated.

In India, especially in smaller towns, street address’s are not as established as other parts of the world. If they did know it, it frequently looked like this: 83, LAXMI APPT., SEC-5, PLOT NO-27/8, ROHINI.

Asking someone to type that out is a usability nightmare.

From this data we now had a new starting point for improving conversions: by making the process of entering address easier or by making the field optional.

How Did We Track Validation Errors with Google Analytics?

In Google Analytics they have an awesome feature called event tracking that can be easily trigger by on-page javascript.

Our site was developed with Rails so when a field fails to validate, it automatically gets wrapped in a div.

So we wrote up a tiny script that:

1. scans the page for any divs with fieldWithErrors
2. grabs the ID of the form field
3. sends an event to Google Analytics with the label “Validation Error” and the value as the fields ID

The script (prototype):

With this data you can see see how many exited the form, what country they are from, validations per user, etc.

Fixing the Problem Fields

It may be beneficial to minimize the required fields to get that initial commitment.

Just like the old sales adage, if you can get the customer to say yes the first time it will be easier to get them to say yes later on for the bigger commitment.

Making fields a requirement is always a tough balance between hurting the forms usability and getting the information you want.

If you do decided to skip the tough questions early on, a process could be set up to get the needed information later on from something like a follow-up email or secondary form.

Either way it helps to have the analytics data to back it up those decisions.

dMix.ca has been redesigned

I have cleaned up this blogs design quite a bit and made it much more minimalistic. With a few ideas in mind:

• Consistent and readable typography
• Removed the sidebar so content is more of the main focus and less self-promotion
• Content is divided into 4 categories: UX, Rails, Marketing and Startups

The redesign was inspired after seeing Dustin Curtis’s awesome blog(azine), but with considerably less effort.

Contrastream has been shut down officially

It’s been about a year and a half since I wrote about why Contrastream never took off, it’s been the most popular post on this site plus writing it was a big reason why I created this blog in the first place.

Over the last 2 years since creating Contrastream I’ve seen quite a few other sites attempt to solve the same problem but nothing has really hit the nail on the head yet. There’s still a need, good indie music is hard to find, and hopefully someone can solve it (Last.fm and HypeMachine have come the closest).

I was hoping to come back to it as a side project but Integrate consumed most of my attention and I’ve recently joined a new startup (see below).

So today, I’ve decided to officially shut it down.

Now working at Learnhub

Last month I joined Savvica, a local startup in downtown Toronto. They are the creators of Learnhub and Jumbotests. I’m responsible for coordinating the User Experience (I plan on writing much more about UX soon) plus some Ruby development and online marketing.

It’s one of the few silicon valley style startups in Toronto and I’ve been having a great time working with the team.

The Scenario: Validate the username is unique as it’s typed into the forms text field

1) Live_validations controller and validation method

Create a controller to store your validation methods and add the appropriate routes.

2) Message partial

Create a partial that will handle the HTML that is returned for the ajax call.

In your form add an observe_field helper (JRails or Prototype required). This helper will observe the field every 0.5 seconds and pass the value of the text_field via params[:username] to the live_validation controller method.

I used accept.png and cross.png icons from Fam Fam.

Done.

JQuery + Rails Plugin Options

For straight javascript there are a few options, such as jQuery Validation and LiveValidations.com; these are great for basic validations (ex. email has a proper format) but they don’t have access to ActiveRecord.

There is also a rails plugin LiveValidations that hooks up to your existing validations and comes with a form builder for the AJAX, but after testing it: it doesn’t work with nested forms and with hundreds of lines of code it seemed like overkill.

I implemented a scheduling system into an app this month and I needed a calendar with monthly and weekly views.

There are over 80 repo’s on github for calendar + ruby. Calendars in rails are a solved problem, right? But oddly I couldn’t find one with a weekly view. All of them are either date pickers or monthly calendars.

So I decided to build my own and I’m happy to announce my first plugin: WeeklyBuilder [Github | Live Demo]

The builder creates a horizontal scrolling calendar, mapping events for each day of the week. The layout is fluid CSS and the hours can be switched from business hours to 24 hours.

The code was inspired by table_builder by Petrik de Heus which is a clean way to generate monthly calenders.

How to Use WeeklyBuilder

First install by downloading the source from github or via command line:
The weekly calendar builder:
The Next/Previous link helper:
The controller code:
Example events model:

The event model only requires 2 attributes: starts_at:datetime and ends_at:datetime to calculate width and position on the calendar. To simplify this for the user, I only ask the user for one datetime (starts_at) and how long it will take to complete, it then calculates ends_at based on those 2 attributes.

Github: http://github.com/dmix/weekly_builder/
Example: http://scheduler.integratehq.com/
Note: The demo uses table_builder for the monthly view and includes a few extra styles on the weekly. Not yet tested on IE6.

Update (03/06): Added a truncate_width method so that long event names are truncated in proportion to the width of the event, this is passed through the week block: |event, truncate|.

I was reading The Selfish Gene on my Macbook this weekend and since Kindle isn’t yet available in Canada, I have to work with what I have. Here is how to improve the experience (thanks to Andrew Burke for the heads up):

1. Download Adobe Reader or the lighter weight Skim PDF app
2. Open the PDF file, rotate view counter-clockwise (cmd+shift+- in Reader) and make it full screen (cmd+L)
3. Set mouse button to turn to the next page
4. Now the hard part: Turn Macbook sideways so the screen is vertical and can be held like a book
5. Bonus: Download Flux if you do a lot of reading at night, it adjusts the screens contrast based on the time of day

Macbooks have really wide screens that are awkward for ebooks when horizontal but great when vertical. The pages are much larger and fit better into the screen. Plus having the mouse button next to your hand to change pages is more ergonomic.

The drawbacks are that its heavy if your not resting it on a pillow and the glossy screen isn’t quite as readable as E-ink.

The conference was Canada’s version of StartupSchool with speakers such as Rick Segal and Austin Hill during the day, talking about raising VC and legal work for startups. There was a lot of good information for early companies but what stood out was the openness of the Toronto tech startup community. In this industry there is no shortage of support for startups online but having a solid local community is very valuable.

We got some quality feedback and a few blank stares (FYI enterprise software can be a tough sell to the social network crowd). We also meet some great people like Leila from Idee and Pema from GigPark.

We’re looking forward to the next meetups, hopefully the “FuckupCamp”-the conference for startup horror stories-that Rick mentioned gets set up.

Advice on what not to do from real world experiences can be more useful then broad recommendations. My own take on the mishaps of my previous startup was one of the most popular posts on this site.

Thanks goes out to Jevon Macdonald, David Crow and Jonas Brandon for organizing the event.

I found a good tutorial on developing for the iPhone but almost nothing on working with Blackberry’s, so I decided to post some notes to help any rails developers creating a Blackberry version of their application.

The goal in creating the mobile version was to:

• Minimize the size of the application
• Reduce features to only those necessary when on the road
• Optimize the UI for the smaller screen

Subdomain

The first step was to set up a subdomain for the site, for example mobile.dmix.ca. I deployed the app using Nginx so I just created a new DNS and vhost following Slicehosts tutorials.

It used to be common practice to automatically redirect mobile phones to the mobile version of the site. But this has recently been deemed bad usability, users should always have the choice. I created an entirely seperate rails app; some people create seperate stylesheets and some variable layout elements depending on the user agent, if thats the path your taking Mobile_fu might help.

Detecting user-agent

Instead of automatically redirecting, I set up a helper to check the user-agent to see if includes the string “BlackBerry”.

#application_helper.rb
def blackberry_user_agent?
  request.env["HTTP_USER_AGENT"] && request.env["HTTP_USER_AGENT"][/(Blackberry)/]
end

#application.html.erb
<% if blackberry_user_agent? -%>
  <div class="message">
  <p>Using a Blackberry?
  <a href="http://mobile.site.ca/">Use the mobile optimized version</a>.</p>
</div>

BlackBerry user agent: “BlackBerry8700/4.1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1”

Phone Simulator

If you want to test the site locally you can download the RIM Smartphone Simulator. Its Windows only so I wasn’t able to run it on OSX (I tried Crossover and can confirm it does not work). If you are running Windows it will probably save you a lot of time not having to redeploy the site to test changes.

The Blackberry Browser

By default the Blackberry Browser is configured to ignore stylesheets, javascript and background colors. To make your life easier as a designer you can turn these on and recommend your users to do the same (configuration is in the options inside the browser). This is much easier to do if an IT department controls your users phones, but to be safe always test with it off.

The HTML/CSS support varies depending on the version of the phone, it has been pretty consistent on any phone released in the last 3 years with decent support. The newer Bold’s have a much better browser (4.7) with almost full support of CSS/HTML and zooming (still about half of the capabilities of Safari Mobile). I knew my users would be using Blackberry Curves, so I only had to test on the browser version 4.6.

RIM has  HTML/CSS reference guides that explain the support each browser versions has for the languages.

Optimizing UI

A few notes on the UI…

• Aim for function over form, these are not iPhone’s
• Fonts are automatically converted to the default typeface and are almost always black unless you specify, it’s probably best to leave it that way for usability.
• Pages formats to one continuous page, so remove any sidebars and fancy layouts you had in place
• I kept the navigation at the top of the page and horizontal, and did not repeat it in the footer.
• Be very strict on limiting the amount of images you use
• Use clear separators between content (such as hr and background colors) to separate different areas
• Remember the small screen and constant scrolling makes it difficult for users to become familiar with the layout so be very consistent in design

Optimizing Javascript/CSS

First ask yourself if you really need Javascript on the mobile version. If you use a framework like Prototype, loading an extra 150kb will eat up your users data plans and if you happen to live in Canada, with the second highest data rates in the world, this is a big issue.
There was one section that I needed Prototype and without it I would have had to rewrite the whole section. So I added a check to make sure it only loads on that one action.

<% if current_controller == 'objectives' and current_action == 'new' -%>
  <%= javascript_include_tag 'prototype', 'effects', :cache => true -%>
<% end -%>

For CSS I recommend going through and deleting all the layout code and everything unused, every KB counts. You should also look into Bundle_fu to minimize the HTTP requests and put everything into one file. I also moved all my assets (JS, css, images) to S3 to improve speeds and so that attachment_fu uploads are accessible by both rails deployments (mobile and full version).

Firebug/YSlow Stats

Here is the result of the tweaks done to the mobile version compared to the full:

I would love to post up screenshots and a demo of the finished product but it will have to wait until the full site goes public.

Some advice is still effective 128 years later.

Glen Gary Glen Ross, this one never gets old…

Walden, another one from 1854

Walden is about Henry Thoreau ignoring the usual “9-5 life” and taking his own path, building a house in the country and living simply for 2 years. Inspiring for anyone making their own way.

Watch the movie Wall Street (and maybe Rudy too)

This one sounds like it was made last week. Was Gordon Gekko running AIG?

Man in the Arena

Need design inspiration? Watch Helvetica

I always end up in Photoshop after watching this one.

And finally,

Frank Sinatra – My Way