Also, I’ve included the actual demo I put together here: Shrugh and I’ve zipped all of the files including the balsamiq source and made it available here: BalsamiqDemosDemo.zip.

Hopefully that will help everyone!

cheers,

EG

These engines were used to make horsehair fly lines. Modern Atlantic Salmon fly tyers like to use them for twisting silkworm gut to snell their flies.

Here are some construction photos:

It starts out a lot like a reel; brass plates cut in to squares, octagons and finally round:





With a lot of gears:





These are small, at 2 1/4″ diameter:





The hooks were actually fairly difficult to reproduce because they are tapered and the tapered section is bent. It is tricky enough making nice bends on straight sided brass rod!



And here is the finished twisting engine, polished and ready to ship. You can see my new logo and maker’s stamps.

The woodcuts I’ve seen show the gears enclosed but I decided to keep mine exposed. It is fascinating watching all of that motion when the engine is in operation! Plus, lubricating the mechanism is much easier. This twisting engine is going to my friend Paul at Historic Angling Enterprises. Apparently, he uses his engine every day to make horsehair snoods. He has worn out several “inferior” engines. I hope mine is over-engineered enough for him!

There is not a lot of space on a reel for a large logo, so I ended up designing and ordering 2 stamps. One is just of the fish logo and the other my maker’s mark with my name and location. Here is a photo of the finished stamp:

The maker’s stamp is only 5/8″ wide so it can be tucked away somewhere inconspicuous. The trout logo is about 3/8″ wide and will look great around the spindle bolt. I purchased these from Buckeye Engraving and they did an excellent job.

Just to complete the story, I also ordered a set of 3/32″ numeral stamps so I can add a serial number to my reels. I use a date and sequence format that contains a lot of information in just a few numbers. So for example, the serial #20090721 indicates my 21st reel made and it was completed in July, 2009.

This is definitely a classy addition to my reels!

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!

Already, in less than 12 hours, “Shrugh” is the 4th hit on Google, has a twitter channel and has been discussed on several blogs. My posts on creating demos from balsamiq Mockups has driven the largest number of visits in a single day to EclecticGuy.com – and indirectly introduced Shrugh at the same time!

So, without further adieu, Shrugh.

The Details

 selection.css now includes a new class to set the display of items of that class to “none“:

.hidden_image {
    display:none;
}

Now, in your first HTML file (usually index.html), you simply need to list the images you want to pre-load and set their class to hidden_image. It is important that you do this at the very bottom of the HTML file so the browser can start to lay out the rest of your demo while it is loading the images. I added them immediately before the </body> tag:

<img src="images/01.png" class="hidden_image">
<img src="images/02.png" class="hidden_image">
<img src="images/03.png" class="hidden_image">
<img src="images/04.png" class="hidden_image">
<img src="images/05.png" class="hidden_image">
</body>

Now, when you open your index.html, the browser will preload all of the images you specified and the demo will be much more interactive! If you have a lot of images or very large images to pre-load, you might consider not loading them all up front. Instead, load only the images needed for the hotspot targets. Then on the target HTML, use the same technique to pre-load it’s hotspot target images – cascading the pre-loading.

And 1 last thing: you can run these demos both from the desktop or from a Web server!

Several weeks ago I blogged about balsamiq Mockups. Now that I’ve really had a chance to use Mockups I am even more impressed with it! I won’t be using paper and pencil for thinking through UI designs any more!

Over the last few weeks I’ve put together a number of mockups and thought it would be really cool if I could link them together based on a user’s click on a hotspot on the image – like HTML image maps. A number of people have asked balsamiq for a demo or storyboard feature – and that would be really cool – but until that day comes, here is my low-budget, but pretty nifty, way to build demos from Mockups or any screen image or capture for that matter.

Here is a little demo that you can try out. There are 2 hotspots on the first page – over the Login button and over the first item in the “Today’s BIG Shrughs” list. Mouse over them and you should see a transparent orange rectangle with a dotted border appear. When you click the Login button, the next mockup screen will be displayed. It has several hotspots too. Explore a little bit before reading the next section.

How its Done

1. Create a folder for your demo. Download and copy the index.html.txt and selection.css files in to your folder. Remove the ‘.txt‘ from index.html.txt – it is just there so you can download the file as text and not as a Web page! Create a folder called images too.
2. Create your Mockup screens and save each as a PNG file. I like to put them in the folder called images (of all places!).
3. Open index.html in your favorite text editor (I use TextMate on the Mac) and change the text between the <title> and </title> tags to your demo’s name.
4. In the #image-map CSS, change the background-image: filename to point to your 1st Mockup PNG file. I like to name my PNGs with simple names like 01.png, 02.png, etc. Also change the height: and width: tags to your image’s dimensions.
5. You will notice that there are 2 hotspots defined in the index.html file you downloaded. If you save index.html and then open it in a browser, you will see these hotspots highlight as you mouse around over your Mockups image. All you have to do now is determine how many hotspots the screen should have on it and create an anchor for each in the <body><div id=”hotspot”> section. Here is an example: <a href=“02.html” id=“signin”></a>. The href points to the destination html file that will include the Mockups PNG file for the next screen. Once you have finished, you need to add a hotspot markup in the CSS style section. Here is an example from the sample:

#hotspot a#signin {

top: 106px;

left: 438px;

width: 333px;

height: 27px;

}

You will need to change the top:, left:, width: and height: to fit the hotspot on your Mockup. Make sure it has the same name as the id tag in the anchor section you created. Create as many of these hotspot anchor sections as you need.

That’s all there is to it! It is a little manual but it goes quickly one you get the hang of it. Take a look at the demo again so you can see how it works. One last thing, you can change the appearance of the highlight hotspot rectangle in the selection.css. The border color can be changed, its width changed, and its style changed to solid, dashed, or dotted. You can also have a fill color (background-color:) and make it transparent with the opacity:. My example demonstrates this. Notice that IE needs a special markup for opacity.

One last thing! You can also add text to the HTML page to tell your users/testers what they are seeing, give a Use Case or anything else you want.

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.