My goal is to have this idea implemented in the next week or so, then we’ll have a complete – but simple – Shrugh prototype.

To check out the new demo. go to the Shrugh home page and click the create a shrugh link at the bottom of the page (or click the link I just typed!). Either way, check out the demo and please leave your comments/feedback at the end!

After I completed the demo though, the juices really got flowing! I am all for keeping it as simple as possible. As Albert Einstein said, “Everything should be made as simple as possible, but not one bit simpler.” Words to live by! So, let me try this on you – please let me know what you think!

1. When a shrugher creates a new shrugh, they pick from 1 of 3 types: Yes/No, Fish for Answer, and Pros/Cons. After picking the type, they enter their shrugh and an optional comment to add detail.
2. Each of these 3 types of shrughs has a different set of responses for users to choose from when they respond to a shrugh – this is the “Is your reply a…” option menu in the demo:
   • “Is your reply a…” Yes or No
   • “Is your reply a…” Verdict, Opinion, Kibitz
   • “Is your reply a…” Pro or Con
3. That is it, very simple. Anyone adding a reply (including the shrugh owner) does so the same way. The choose what their reply type is (see the list above) and then type in the reply. Very simple. Pros and Cons also have an “importance” (weighting) option 1-5 that can be set.

As I mentioned in the last status update, I had done some prototyping in both Ruby on Rails and Google App Engine to determine which direction I want to head. To be sure, this was not an apple-to-apple comparison. RoR is really a programming language and Web framework. You still have to choose an RDBMS (most likely MySQL since I have a lot of experience with it), find a hosting service, and deal with deployment and other issues. Google App Engine, on the other hand, is a complete Cloud Computing environment ready to go. It currently uses Python for code development, the Django Web framework, and Google’s BigTable object store. This all runs on Google’s App Engine environment – which provides automatic scalability, reliability, robustness, automatic application versioning and a host of other capabilities. In addition, it is free to get started (pricing model is usage based so it scales with the application). Finally, Google provides a really nice freestanding development environment that includes a simulated BigTable datastore along with the other services. It is very easy to download and start using this environment.

So, with the demo Mockups and user feedback “on screen”, I began by designing the “model” for Shrughs and implemented them iteratively in Python. Similar to Django, App Engine uses a Model class for managing data storage.  You write your model as a Python class and App Engine does the rest. This makes it very easy to just jump in and get started.

My goal for this first iteration was to create a reasonable model for Shrugh objects, display them on screen using CSS and a templatized presentation (also part of Django), and deploy all of this on Google App Engine. This would give me experience with the entire cycle of develop and test locally then deploy, test and activate on The Cloud. That’s a lot in a short time!

So, I knew that a Shrugh needed to have these attributes: an owner, a type (yes/no, list, pros vs cons), the actual question, and a few access control attributes. Here is what I came up with:

class Shrugh(db.Model):

	owner = db.UserProperty()

	shrugh_type = db.IntegerProperty(default=0, choices=set([0,1,2]))	

	question = db.StringProperty(multiline=True)

	comment = db.StringProperty()

	share_on_open = db.IntegerProperty(default=1, choices=set([0,1,2]))

	created_datetime = db.DateTimeProperty(auto_now_add=True)

	close_datetime = db.DateTimeProperty()

	share_on_close = db.BooleanProperty(default=True)

	everyone_add = db.BooleanProperty(default=False)

A few things need to be said about App Engine and BigTable that are demonstrated in this class. First, you’ll notice that I derive from db.Model. Model is the superclass for data model definitions whose properties are static. There is another form, db.Expando, which is a superclass for data model definitions whose properties are determined dynamically. I chose Model simply because that seemed easier to get started.

Next, you’ll notice that owner is a UserProperty. App Engine is tied to Google’s user model through UserProperty. This is one area of App Engine that I am still trying to wrap my head around – and apparently so are a lot of other developers based on the number of discussions and blog posts on this subject! Ideally, Shrugh users would not have to have a Google user account. That’s fine for now during the early development stage though. (turns out that Django has its own user model and it is possible to combine it with Google’s to support Google users and non-Google users.)

You’ll also notice that some properties have a default value as well as pre-configured values (choices) for the property. This is all very easy to do.

Probably the biggest difference with BigTable and traditional RDBMs is that queries using GQL (Google’s SQL-like query language) can not perform “joins”. Unlike RDBMs, BigTable uses a distributed architecture to manage scaling to very large data sets. Developers can optimize how data is distributed by describing relationships between data objects, and by defining indexes for queries. Defining a relationship is straight-forward, simply use a ReferenceProperty to another model instance. Defining indexes for query optimization is a little less friendly – both in how it is done and in how it is deployed on the App Engine service. Defined indexes are also required for sorting result sets (like date/time ordering).

Indexes are defined in the index.yaml file (part of an application’s configuration). Once you realize that and understand what needs to be indexed and why, creating the indexes is not too tricky. The nasty part comes during deployment. When you upload your application to App Engine, the service looks at this yaml file and builds the indexes. There are reports of this taking 24-36 hours! My experience creating a single index on created_datetime (so that I can sort query results) was not very positive. I ended up having to create 2 different “applications” on App Engine before I finally got it right. The first time, App Engine completed the index build in about 30 minutes but execution resulted in a terminal failure. I never figured out why! Finally, after some reading and experimenting, I was able to upload my Shrugh prototype and App Engine built the index in about 10 minutes. Here is the current version: Shrugh Development Version.

One quick sidebar, the Google AppEngineLauncher application for Mac OSX is really nice! It manages the local application server as well as uploading to the App Engine service along with log viewing and access to the App Engine Dashboard. Here’s a screenshot:

So, in just a few hours, I had defined a model for a Shrugh and wrote some code to display Shrughs in a decent layout with a little form to let users create a Shrugh and choose a type. Not bad!

May I trouble you one more time to run through the demo and give me your comments? Simply go to www.shrugh.com to get started.

About the Name

The overwhelming majority of you like the name Shrugh and even figured out how to pronounce it! A handful of people couldn’t figure it out, so here is the story on the name:

The name “Shrugh” stems from the concatenation of “shrug” and “ugh” pronounced Shru-ugh. A “shrug” is body language that is often used when a person is confused or indecisive. An “ugh” is an exclamation of “I don’t know” or “this is going to hurt”! Shrugh seemed like as good of a name as any, and the domain name was free and clear!

Demo Details

Many of you asked for more details about the demo itself. Well, as I wrote on my blog “Assembling demos from balsamiq Mockups” I use a product called balsamiq Mockups to design the screens (I blogged about Mockups here). Mockups creates static screens and has the ability to export them as PNG files. So I developed a technique using CSS styles to let me link static screens together to create a demo of sorts. That is how the Shrugh demo works. One handy trick that I just thought of and didn’t mention in either of my updates to the demo technique, is to show the “hotspots” while you are figuring out what their coordinates are. If you use my css source file “selection.css“, you will see a commented out style at the bottom. If you uncomment this style, you will be able to see your hotspots while you work on the demo! Just comment the style out before you present the demo.

Shrugh Demo Lessons Learned

The current Shrugh demo has 43 Mockups PNG screens and 48 HTML wrapper files. You’ll notice that the top of each page has a link to take the user back to the Shrugh Homepage. My friend Bob made that suggestion and it has been well received! I also added a Google Form to collect feedback directly as part of the user’s demo experience. It was very easy to create the form and it tabulates all of the feedback in a spreadsheet so it is easy for me to manage. Finally, I include a short description and explicit directions on what the user is seeing and what they should do next. That has really helped too.

One comment on demos done this way, they do result in more screens and user clicks than the actual product will have. The reason for this is that the PNG files are of a fixed size and trying to kludge vertical scrolling would have been time consuming. So, rather than have a single screen to create a shrugh, it is divided between 4 screens. It will be a simple matter to combine these elements on to a single screen and significantly improve usability. Thanks to all those who commented on this!

What’s Next?

While I’ve been developing the demo, I’ve also been looking at implementation technologies and platforms. I had narrowed it down to two – Ruby on Rails and Google App Engine. They are very different platforms, each with strengths and weaknesses. So, I did a rapid prototype on each to test capabilities and get a feel for them. I developed the same application on each – a simple Yes/No shrugh creation screen that saves the shrugh to a database and displays shrughs in a list. It was actually easy to build this on both technologies but in the end, I chose Google App Engine as the platform of choice for several reasons:

1. It is a new cloud computing platform and I am very intrigued with the future of cloud computing. What better way to learn about it than to actually develop an application for one?
2. Google App Engine currently supports the Python programming language and I already know Python.
3. Google App Engine also supports the Django Web framework. Both Rails and Django support the DRY principle but I really like Django’s URL scheme and templating. (Rails relies on 3rd party modules for more powerful templating, like Liquid).

Azure Services Platform

As you can see from this Microsoft marketecture diagram, Live Services, .NET Services, SQL Services, Sharepoint Services, and Microsoft Dynamics CRM Services are all layered on Azure. The platform supports HTTP, REST, SOAP, RSS, and AtomPub – a well rounded set of modern services protocols. Unlike Google’s and Amazon’s services, Azure is very focused on enterprise applications. An SDK is available today.

These are exciting times, exciting times!

Until I stumbled across balsamiq, my all-time favorite Micro ISV was Ed Hamrick of Hamrick Software, developer of VueScan. I’ve never met Ed but I did spend several hours on the phone and many email exchanges with him a few years ago when I started Pixingo (a Mini ISV). Ed has a fantastic product and business – the type to envy if you are a “do it yoursefer”. Hamrick held the spot as “super hero” in my mind for more than a decade, then along comes Peldi Guilizzoni of balsamiq.

While I was doing some research on Crowdsourcing, I came across a Blog post on ReadWriteWeb on helping Twitter find a revenue model – maybe the ultimate in crowdsourcing! As I read through the comments I came across Peldi Guilizzoni’s posts on his use of Twitter for targeted marketing of his company’s products. The first thought through my mind was “Brilliant!” (followed closely by “When’s lunch?). Peldi is the brain and braun behind balsamiq. As I dug in to the company (I hadn’t even looked at what their product was yet!) I discovered a kindred entrepreneurial spirit! Then I looked at the product, Mockups!

Mockups is a newgen application for mocking up software user interfaces. Sort of paper prototyping on steroids. Those that know me also know that I am passionate about usability and involving users as early in the inception and design phase as possible. I’ve played with a lot of prototyping tools in the past and am an avid paper prototyper. In fact, my company shipped Genesys in 1989 – a tool that allowed a developer to draw their user interface and Genesys would generate source code in their choice of 65816 Assembly Language, Pascal, C or Apple RES format. [This is COOL! A quick Google turned up this link on Genesys: http://www.whatisthe2gs.apple2.org.za/genesys/ It even has a screenshot of our manual!]

Mockups was designed to be as simple as possible but yet allow rapid design and design exploration. It has a retro hand-drawn look and appeal to it too. As a newgen app, it can run as a desktop application on WIndows, Macs or Linux, as well as in a browser or even embedded in a Wiki! Versions supporting the commercial Atlassian Confluence or OpenSource XWiki are available. This is truly brilliant and shows how the power of Wikis can be very effectively exploited for team-based product design as well as getting customers involved in the design process.

I’ve been using the trial version of Mockups heavily for a day now (both desktop and XWiki versions) and have a good handle on how it works and where it’s strengths and weaknesses (very few) are. In many ways, Mockups is like a drawing program with a library of over 60 pre-drawn UI controls. These look just like you drew them with paper and pencil!

(from the balsamiq samples)

I think the hand-drawn look helps reinforce that notion that this is a design idea and not a polished product. I used to use Photoshop with a collection of UI images to build screen designs that looked so real that users just assumed they were a final product and got bogged down in little details and not the big picture around usability. Mockup allows the designer and test subject to see the bigger picture of usability.

Just for grins, I used Mockups to prototype a Fly Tying database product I developed a few years ago. It took all of 5 minutes – without having read any on-line help – to create the main screen and several dialogs. It would have taken me longer with paper and pencil since I do a lot of erasing!

Mockups is so easy and fun to use that I found myself drawing designs for several product ideas I have had floating in my head. Now I have captured these and can share them with others. The XWiki embedded version of Mockups automatically versions edits – a very cool feature that allows you to see how an idea evolved over time. Since the mockup is embedded on a Wiki page, you can annotate, comment and collaborate seamlessly.

I’m sure that I will have more to say about balsamiq and Mockups in future posts, but for now, if you are a software developer or designer, give Mockups a serious look.

Back in “the day” we dialed in to on-line communities called bulletin board systems (BBS) using 300 baud modems. My first modem was even acoustically coupled! This was back in the mid 1970s. There were relatively few communities back then – basically any individual with a personal computer, 1 or more modems connected to it, and some central theme or topic could set these up. It was tough to even find what was out there since there were no central directories for these message boards. But some of these BBSes became very valuable for knowledge sharing amongst interested users from all over the country and sometimes, the world.

Even back then I had a lot of interests and I used this new technology (which, of course, was another interest) to find experts and discover knowledge. From the beginning, it was easy to find BBSes that supported communities of early computer geeks – hardware message boards helped me build my first Z80-based computer from scratch and programming boards helped me learn to program it in assembly language. But I also found and participated in BBS sites that specialized in Studebaker cars and their restoration (my first car was a 1957 Silver Hawk), black powder gun making and shooting, archery, remote controlled model airplanes, remote controlled model cars, and one of my favorites, a fly fishing BBS with trip reports, techniques and fly tying patterns.

The Usenet and commercial BBSes with subscription fees started to emerge – CompuServe, Q-Link/AOL, and too many others to recall. By the mid 80s you could, with a little effort, find information on most any interest you might have. What was amazing about all of these, was that they had very active user communities that were willing to share their knowledge, help newbies, and just socialize. These were the precursors to today’s Web Forums. I think many of the earliest participants may have come out of the Amateur Radio world (btw, amateur radio operators were one of, if not the, first to use technology to create virtual communities consisting of members from all over the planet. They still do in fact).

These early BBSes offered 2 primary capabilities; 1) the ability to traverse a file directory and download or upload documents and 2) threaded discussions with other members. Virtual communities were simple but effective then. There was a lot of camaraderie on these early BBS sites with very few lurkers – most sites had near 100% participation. This was probably due to the fact that It took a fair amount of effort to find and visit these sites, so users that stuck around after their first visit or 2 stayed engaged.

As the internet became accessible to the masses, most of these BBSes gave way to Usenet and commercial forums like CompuServe. For a short time in the early 1990s, Gopher was hot but it quickly gave way to the new, very cool World Wide Web (WWW). The Web really lowered the accessibility bar (a good thing BTW). Now people from all over the world can form communities for all topics imaginable. In just a few decades a completely new, universally accessible and extremely rich communication and social networking infrastructure was created more or less organically. Even though Social Computing is a hot topic today, people have been leveraging computers and networks to help and learn from one another for quite some time.

Here are a few of my favorite communities (in no particular order) in which I actively participate:

Pelican Porsche Forum

Early Porsche 911S Registry

Fly Tying and Rod Building Forums

New England Kayak Fishing

RC Groups

Facebook

LinkedIn

Photography-On-The-Net

1) Mobile device manufacturers are keeping tight controls on application development on their platforms

With the exception of Apple’s iPhone and the future possibility of Google’s Android, developers have to jump through hoops and pay for the privilege of developing on the platform. Talk about stifling innovation! These same mobile device manufacturers have not put any significant effort in to improving their Web browsers – the technology that can either make or break the “Mobile Web”. If the mobile browser is inadequate, the mobile browsing experience will suffer and users will not flock to the web. If these platforms were developer friendlier, innovation on the browser would have started sooner. The Mobile Firefox project could provide some relief.

2) The mobile carriers are gouging the market with high cost data services

With the high cost of data services (upwards of $35/month), only hard core technophiles and those with corporate expense accounts can afford/justify it. Think about how ridiculous .25 an SMS message or $10/month for unlimited text messaging is! Text Messaging – the stuff you do for free on IM on your laptop! And with the pitiful browsing support on most handsets, the Mobile Web is not going to drive users to subscribe. The folks at RIM have at least got email “right” and that does indeed drive a lot of corporate usage.

Have the device manufacturers and carriers killed the Mobile Web? I don’t think, so but they have kept it languishing for a long time. Back in 1999, the wireless Palm VII offered the first glimmer of how powerful and simple the Mobile Web could be. The service was $15/month (for the base limited page view service) and special “Web Clipping” apps were required (and there was no fee to develop them). But you know what, they worked really well and a lot of companies jumped on the “PQA” (Palm Query Application) bandwagon. I bought a lot of books from Amazon using the Amazon PQA and finding the nearest Starbucks was dead simple. Without GPS, the Palm VII could locate you based on the cell network – this was in 1999! How cool is that? I finally have this capability again on my iPhone.

I see a change in the tide coming. Firstly, the iPhone is truly spectacular. It tears down the barriers of a closed system – which will allow real unimpeded innovation. It provides an amazing Web browser, the Mobile Safari browser. Granted, Mobile Safari has some limitations in its first release but, wow, what an amazing browser it is. The touch interface is superb and the resolution and colors are spectacular.

Secondly, the carriers are starting to see competitive pricing pressure. Sprint recently announced their Simply Everything Plan that gives unlimited everything – voice, SMS, email, Web browsing, GPS, picture and video messaging – for $99.99/month. Still a big premium to pay but a step in the right direction. Even the iPhone rate plans are attempting to reduce the cost of unlimited data services.

So, what does all this mean? If you’ve ever used a Palm VII, Blackberry or, especially, an iPhone, you know how convenient and powerful mobile Web, email and data services done “right” can be. The iPhone is mere weeks away from ripping down the walls that have held in innovation for too long, Android will (hopefully) follow within a year. We are not hearing the last gasps of the Mobile Web, rather, I am reminded of that scene at the end of Braveheart when William Wallace takes in a breath of air and clearly yells … “FREEDOM”!

One of the best things is that the SDK is a complete, standalone system that includes a Web server, the App Engine framework, support for Datastore, Users, Mail and URL Fetch Apis, and the Django template language – all in a 2.3MB (Mac OSX) download! You develop in the dev environment and then deploy to Google’s App Engine and its scalable infrastructure.