Windows Updates that never seem to end

It seems like a very long time since I posted anything. I just checked my blog stats and I am 20,000 page views now, which is pretty good since I so infrequently post anything any more.

The other crazy thing is that every time I use a Microsoft Windows machine I feel like creating a new blog post to relieve the stress that was imposed on me by using Windows. I almost never use Microsoft products any more but this week I had to use both Windows 7 and Windows 8 laptops. I know several people who have had problems with their new 2014 MacBook Pro laptops, which makes me very sad. Even fighting those issues, they are still better than using Windows. Let me explain why...

At the customer site where I am working now, we have a Dell laptop set aside for running usability studies when we need in person on-site testing. We had not used that laptop since April of this year. I knew that was asking for trouble since I knew there would be many Windows updates. I just never thought there would be 81 of them and after 2 reboots and 2 hours later I had the laptop in working order. There are still a couple of old programs installed that are constantly sending notifications to the screen that I have to see but don't help me in any way. Too painful to even find how to uninstall them so I just let them be by ignoring them as they only show up each time I reboot and login. They will not appear during our usability study sessions so I don't have to waste any more time on that laptop.

Then came today when I had to add TechSmith's Morae Observer to a Windows 8 machine. It is the same machine I used last year, at this time, to create the Windows Store app that I blogged about during the  6 weeks. I seldom use the laptop but some of the guys at work use it to validate their web apps. I started that baby up today and alas there were all kinds of updates. It took me 3 reboots and 3 hours to wade thru them. Several of them were so slow that I thought the machine was completely locked up. I tried to be patient and finally I had a usable laptop. It has to be an accident that there is a direct correlation between the number of hours and reboots I have suffered thru on two different laptops.

Now I need to vent... One of the updates was to download the latest Zune player. I really thought iTunes and iPods had killed the Zune player, but I assume the latest Windows phones must have it installed. I am willing to try anything once I thought I would give it a try. It turns out that is just about the worst looking app I have seen in a long time. It kind of reminds me of the old Winamp audio player with a very bad skin. Some screenshots are in order...

The first bit of bad news is that I have to watch a very pink and orange progress screen for a long time as it took way too long to install this one app:

It is not easter and I don't need to see a magic trick of a bunny popping out of a hat when the install is finally complete:

The first subsequent screen presented to me is a wizard to help find music for me. Zune asked me to select the 3 music groups I like the best. I entered the great Jeff Beck as my first choice and then I got this error screen. I guess what they really meant was it would be magic if you can actually enter 3 but you can try if you like being a magician.

I needed a break and went to my Mac to Skype my buds at work and to relieve some Post Traumatic  Windows Stress Syndrome from this process. I came back to the Windows 8 laptop and then saw this confusing bundle of tiles. As you move the mouse over the Zune window all kinds of things happen none of which are helpful. I finally gave up as I realized I was never going to use Zune ever.

Google Custom Search Engine

Finally after much work I have a Google Custom Search Engine working for a public site I am working on for a friend. In the past I have worked on many internal web sites or private forums so I did not need for them to be located in a public web search. I have many times wanted a way to search thru this content without having to write my own custom search. So this week brought me to the place where I wanted to try to create a custom search using Google.

This is where I started my adventure in googling. I also needed to know the format to allow image, video, audio and PDF files to be indexed in the search. I also need a nice summary that helps me thru the process so this article was so helpful. I then thought it would be nice to have a tool that just does all of this for me and google provides a list of validators and generators. I tried a couple of them and was not happy with the results. I found myself referring to video format page as it was the hardest one to solve. Since all of the videos are stored publicly, I found this page that explains how to add them from Vimeo correctly. The nice thing about that page is that it describes how to get this working in other video formats also.

I first started by creating my own Google Custom Search Engine and then add the top level URL as the main index page. I waited a full 24 hours to see what the Google found by default. The results were disappointing as it never found more than the initial 9 pages I had at the time when I defined the search engine. I tried and tried and could not find a way to get the new pages to show up.

My next attempt that to create a list of URLs by using an on-line site list generator. That gave me a list and after waiting 24 hours that gave me all of the pages showing up in my search, including content inside my text based PDFs.

My next attempt was to add a site map directly in the Google Custom Search Engine  control panel. But after waiting yet another 24 hours I found that it did absolutely nothing. That is when I realized I was not doing something right. I clicked on the grey question mark next to "Identified Sitemaps" and it had a linked to "Submit a Sitemap". That is when I learned about Google Webmaster Tools and the ability to validate my site map. The odd thing is that I had already validated it on a couple of sites and they both said the file was valid. When I loaded my site map to Google Webmaster Tools in order test it, I saw all kinds of odd errors. The list of error codes is always helpful as there is no way to get the site map XML correct the first time as I was creating it manually myself.

Finally I have a working site map, but it took me over a week working part time on weekends and at night. I have to wait until the video and images are processed so by tomorrow I should be done with this whole affair. I have to honestly say that it is not a love affair as I did not really enjoy the process and life is all about enjoying the journey so I need to find a another adventure that is more fun.

Protection by obfuscation?

Why did Apple make it so hard to build and deploy iOS apps for user testing? Why did they make the process so complicated that a lay person cannot understand it? I build and deploy seldom and when I do I never get it right the first time. It has been three years since I first deployed an iOS app for user testing. The process has changed three times, so even if you learn it once that does not help as you solve the immediate problem as you have to relearn the process over and over again. I am not talking about a couple of easy steps. Oh no, this is way beyond the short term memory of recalling seven things. It has gotten more simple over time which means a higher chance of success, but it is still way too many steps. If you get one step wrong then you are in trouble as the app will not load on the physical device and you get the deadly message that the app failed to load. Sure you can dig around and find the console log on the iPhone and see crypt messages like the following:

iPhone installd[62] : entitlement 'keychain-access-groups' has value not permitted by provisioning profile '...'

iPhone installd[62] : 0x201000 verify_signer_identity: MISValidateSignatureAndCopyInfo failed for /var/tmp/install_staging.CAh7po/foo_extracted/Payload/...: 0xe8008016

iPhone installd[62] : 0x201000 do_preflight_verification: Could not verify executable at /var/tmp/install_staging.CAh7po/foo_extracted/Payload/...

iPhone itunesstored[103] : 0x1f6f000 MobileInstallationInstallForLaunchServices: failed with -1

iPhone itunesstored[103] : ERROR: MobileInstallationInstallForLaunchServices returned nil

Apple might as well have just put an item in the log that says you failed, so try again. How can a company like Apple that prides itself on design and ease of use in it's consumer products, make something so hard and difficult? Could it be that by making this so complicated that they have protected the average person from having the patience to figure this out by obfuscation? I have to give them the benefit of the doubt and assume that the whole process was not designed for ease of use but was added as an after thought when the iPhone just took off and sold a gazillion units.

The other problem I have is that when you sign up for an Apple developer account for $100 per year, you only get 100 physical devices where you can deploy your prototypes. If you test an app with 10 people and then never interact with those 10 people again during the year, you just lost 10 of your 100 devices. Now you see why people don't do user testing with real apps outside the Apple Store. If you have the physical devices connected to your Mac then those do not count against this device limit. How is this helping UX designers do user testing?

Please quit reading now if you are tired as the following may wear you out by just reading it...


Let me summarize the steps to deploy a TestFlight build so you can user test a prototype:

1) create a TestFlight account on the web (http://testflightapp.com)
2) create a Team within TestFlight
3) invite people to join the TestFlight Team as testers by sending them an email that they have to read on their iPhone
4) wait for the people to respond and then go back into TestFlight and export all of the contact info from within TestFlight Team screen

NOTE: congratulations as that is the easy part - all you have now are the unique iPhone identifiers for each person, so now the real fun begins

5) you have to have an Apple developer account and the Apple development environment called Xcode loaded on your Mac
6) log into the Apple developer account (http://developer.apple.com)
7) select "Certificates, Identifiers & Profiles"

NOTE: this is a 3 step process as you need a certificate, valid devices and a provisioning profile (it will be 4 steps if you want to create a unique application ID but I am not going there as that is optional and only needed for deployed Apple Store apps)

8) select "Development" under "Certificates" section
9) "iOS App Development" should be selected by default and grayed out, which is already confusing
10) select "App Store and Ad Hoc" since you cannot continue without select a "Production" radio button even though we are not generating a production build, confusion is starting to really set in now
11) the next screen is a set of instructions that you must follow using the Keychain app on your Mac, I forgot to mention the obvious but you cannot deploy an Apple app without a Mac, but you are free to use iTunes to connect your iPhone to your Windows computer!
12) after following those directions, you then load the generated CSR file into the Apple developer web site

NOTE: only two more sections to go, but you are getting the idea that only the brave in heart can actually get all of these correct the first time and not give up as extreme patience is needed

13) select "Devices"
14) select "+" to add new devices
15) select "Register Multiple Devices"
16) select "Choose File..." button and select use the exported device list from TestFlight

NOTE: finally something was not so bad, but then we start the really confusing part

17) select "Provisioning Profiles"
18) select "Development" under "Provisioning Profiles" section
19) select "+" to add a new profile
20) select "iOS App Development" radio button
21) select the "App ID", which should be your default Apple account ID or if you really go crazy then it would be the new application ID you created just for this prototype
22) select the certificate that you already created as it should appear in the list
23) select all of the devices you already added - if you need to add another one you get the honor of skipping the first 12 steps and going thru the rest all over again
24) name the profile
25) select "Generate" which will save the "mobileprovision" file in your Downloads folder
26) double click on the file to load that into Xcode

NOTE: now if you did everything by the book and nothing bad happened then you are almost done - now the following is the MOST important step and the easiest to get wrong

27) select the Xcode project file and make sure the build settings have "Code Signing Identity" set to the same value as the Certificate added to your Keychain - I open the Keychain app and select "Certificates" and scan for "iPhone Developer" and look for the Hex value at the end of the name - this is the same Hex value that must be selected for everything including Debug and Release
28) clean the project and rebuild it
29) easiest thing to do now is to install the TestFlight app locally on your Mac and start it up so it is visible in the system menu as the archive build in Xcode will send a notification that can be send to the local TestFlight app running on your Mac
30) select "iOS Device" as the target and then select "Archive" under the "Product" menu
31) when archive notice appears, end it to the TestFlight app
32) following the steps to add a comment, select all of the devices and send an email notice (the first time you do this, it would best to not send out an email since chances of success are slim to none)

NOTE: each device in the distribution list will get an email and iPhone notification that the build is ready

The good news is that on success you feel like celebrating as this was a huge accomplishment.
The bad news is that if you have to do this a lot then you are motivated to find a way to automate this somehow.

Why should you create a prototype?

"You are iterating your solution as well as your understanding of the problem" - Aza Raskin

What do you think of when someone mentions building a prototype? We readily use this word in creating software these days, but the origin of this term in manufacturing is relatively recent. The concept of building an electronic version of a product first to validate that it can be built before starting the expensive process of manufacturing a product came into existence in my lifetime.

Just a short twenty years ago I worked on a product that helped optimize the design of aircraft engines before they were manufactured. This product saved our customers millions of dollars. Why? A Boeing 777 engine has 3 million parts provided by 500 suppliers. There are so many constraints involved that changing one simple parameter has ripple effects throughout the engine. What needs to be done to save money, reduce weight and increase efficiency? This is clearly an engineering manufacturing problem.

So we may not be able to achieve as great as results in designing and building software products, but the idea to quickly create something to be reviewed with consumers of the software has a direct benefit to us a well. It seems so obvious to me to build prototypes as that is what I love to do, but I need to step back a bit and explain why they are useful.

Let's start with low-fidelity prototypes first. Now many times have you heard about people starting a company by drawing their ideas on a paper napkin during a lunch meeting? In today's terms that can be translated into creating a Minimal Viable Product (MVP) as quick as possible. In the UX world this is manifesting itself in the popularity of sketching on paper or whiteboards. The idea is the same in both cases, as you want to fail early and inexpensively when it is easy to change directions. When showing end users a low-fidelity sketch, you want to get them to look past the visuals and concentrate on the tasks, scenarios and workflows to validate we have captured them correctly. In this day and age people expecting pretty visuals so this is not always easy to accomplish successfully.

Next up we skip to high-fidelity prototypes. These are visually appealing with nearly complete set of graphics and sometimes fully functional by using fake data that is relevant to the user context. The only indication that these are prototypes and not a real application may be that only certain paths are working. The textual content will be mostly complete so all parts of the app can be tested with real end users. These are really useful to demonstrate progress to upper management or to gather excitement with the sales staff on a new product. The hardest part of building these is to know when to stop and which level of detail is just right. It is too easy for people to keep asking for more functionality to be added to prototype.

Now we have arrived at the ideal, where we build medium-fidelity prototypes. It more than just a sketch but does not take as much as time as a fully functional great looking prototype. The key is to build just enough to communicate the intended design and to get everyone to participate. Whether user testing or giving demonstrations the idea is to catch mistakes early and to quickly correct them. This can be a great tool to gather detailed requirements on what the product should do and to gather feedback.

"The value on an idea is zero unless it can be communicated" - Aza Raskin

Quotes on creating prototypes

Fail early and inexpensively - Real innovation always includes a risk of failure. By building a prototype, you can quickly weed out the approaches that don’t work to focus on the ones that do.  

Recognize That Ideas Are Cheap - The expense lies in testing and verifying what has economic value. A great prototype is often the best way to start a dialogue with potential customers and test your idea’s value.

Start With a Paper Design -  For a user interface or Web software prototype, a paper design is efficient and effective for quickly working through the functionality. You can get peers and, hopefully, customers to give feedback on where images, text, buttons, graphs, menus, or pull-down selections are located. Paper designs are inexpensive and more valuable than words.

Put in Just Enough Work - here are two good reasons to prototype: the first is to test the feasibility of a software product, and the second is to create a demonstration and gain customer feedback so you can price and put a value on your innovation. Keep these objectives in mind and be careful not to fall in love with the process.

http://www.ni.com/white-paper/8752/en/

Find Design Issues Early - Things we conceptualize in our heads that seem awesome regularly turn out to be terrible ideas when we put them in a more concrete, visual medium such as a piece of paper or a computer screen.

Compare Design Variations Quickly - Comparing several designs with each other is made easier through prototyping. What’s a better solution: a tabbed navigation menu or a list of links arranged vertically?

Gather Design Feedback Better - By simply describing your user interface ideas, it may be hard for others to grasp what you’re trying to achieve. This can result in poor feedback due to misinterpretation.

Prototypes can be a Presentational Tool - Prototyping your design concepts can be an effective way to illustrate your ideas and get approval/sign-off from your higher-ups.

Be Able to Perform User Testing Early On - A prototype can put user testing at the start of a project, instead of at the end.

Prototyping is Cheap, Fast, and Easy

http://designinstruct.com/web-design/prototyping-is-essential/

By definition, prototypes aren’t perfect because their purpose is pragmatic; they elicit feedback.

Prototypes should be, above all, quick and painless to create.

http://www.uxbooth.com/articles/considering-prototypes/

How to prototype and influence people

To design is to inspire participation.

The value of an idea is 0 unless it can be communicated.

To convince yourself and others of an idea.

You are iterating your solution as well as your understanding of the problem.

http://www.azarask.in/blog/post/how-to-prototype-and-influence-people/

Prototypes are a much better at communicating a design. It’s much easier to sit down with designers, developers, product owners and of course users to get feedback and to run through design ideas if everyone can see how things might work with their own eyes.

Prototypes are more user friendly. Where as people are often scared off by wireframes everyone understands what a prototype is (just make it clear that prototypes are very different from the finished article).

Prototypes require less documentation as they are less open to interpretation and on-page interactions can be mocked up. If you do need to document your prototypes (hopefully with an emphasis on ‘just enough’ documentation) then you’ll find yourself having to write many fewer comments for a prototype than a set of wireframes.

Prototypes better support user-centred design. It’s much easier to carry out usability testing with a prototype than a set of wireframes and to get lots of juicy feedback from users in general.

Prototypes require less work. If you are careful to prototype ‘just enough’ to get the feedback that you need then prototypes typically require less work than wireframes because you’ll need to write (and maintain) less documentation.

http://www.uxforthemasses.com/rapid-prototyping/

Visual fidelity (sketched ↔︎ styled)

Look and feel are the most noticeable dimension of a prototype’s fidelity and, if not properly selected, can sidetrack prototype reviews. Go hi-fi too soon and users will focus on visual design, which is not appropriate in early stages. From a visual standpoint, prototypes do not have to be pixel perfect but should be proportional; for example, if the left navigation area has to occupy one-fifth of a 1024-pixel screen, it does not need to be exactly 204 pixels wide, as long as it is proportionally depicted in the prototype. As prototyping progresses through the design cycle, increase visual fidelity as needed by introducing elements of style, color, branding and graphics.

Functional fidelity (static ↔︎ interactive)

Does the prototype reveal how the solution will work (static) or does it appear to be fully functional and respond to user input (interactive)? This dimension is less of a distraction to users, but adding interactivity in subsequent iterations increases functional fidelity and allows the prototype to be used for usability testing and training and communications.

Content fidelity (lorem ipsum ↔︎ real content)

Another dimension that often distracts users is the content that is displayed in the prototype. Squiggly lines and dummy text like lorem ipsum are useful to avoid in early stages of prototyping. But as the prototype is refined, evaluate the need to replace dummy text with real content to get a feel for how it affects the overall design.

http://www.smashingmagazine.com/2010/06/16/design-better-faster-with-rapid-prototyping/

Low-Fidelity - sketches, sticky notes, whiteboards (easy to create and inexpensive to change)

Medium-Fidelity - partially complete for a single workflow or task flow for user testing

• Communicate design - A prototype demonstrates to a client what functionality the system will deliver and what it will be like for users to interact with that system
• Allow for participatory design - Available to the client team, the development team and a wide variety of users, prototypes lend themselves to a participatory design process where many key roles have to "buy-in" to the nature and behavior of the final product.
• Catch mistakes early - Ideally, prototypes are frequently tested in formal and informal usability sessions throughout their development.
• Support iterative development - In this way, the Web site or application interface can evolve (through the process of either adding, refining, or removing features and functionality) until it reaches a stable state.
• Facilitate detailed requirements gathering - Because prototypes provide a common ground of understanding between users, client team members, and development team members, they greatly help in establishing business requirements, application requirements, and use cases.
• Guide later development stages - Application Developers can use the prototype as a live representation of the use cases (even to the point of using prototype pages as a test front-end to their code) and to understand how the system is intended to interact with users.

High-Fidelity - complete graphics and functionality and tie in to dynamic data sources

Caveats of prototyping - Yet it is easy for both clients and team members to want to see more and more functionality and detail included in the prototype

http://www.inovdesigns.com/prototypes.php

The best arguments in favor of low fidelity prototypes are:

1. Fast to build
2. No technical or design ability required
3. Prevent tunnel vision — don’t distract the end user with visuals
4. Get good feedback fast

The reason high fidelity works so well can be summed up with one word: Engagement. No matter who your stakeholder – executive, end user, developer, UX pro – higher fidelity prototypes grab and hold you users attention much more effectively than low fidelity.

http://community.protoshare.com/2013/02/high-fidelity-prototypes/

Choosing the right visualization

As of the start of this year I became the director of sponsorships and memberships for local chapter of User Experience Professionals Association (UXPA). The first thing I envisioned that I need to learned about was what the current and past members liked and disliked about our organization. It was time to create survey to get some input. With hundreds of members I was expecting a potential problem of gathering too much data, but that is a good problem. I thought of using SurveyMonkey or WuFu Forms. Then someone mentioned Google Forms, so I found them very easy to setup and use. I created two forms, a simple one for past members comprised of three questions. I wanted to give open ended questions to let them freely share their thoughts. I created a second form for active members where I wanted to gather more detailed information. I shared the two forms with the other executive members to get their feedback. That one step was the best decision I made in the process. A couple of them had great ideas which made the forms even better. One of the board suggested I look at a government site on building surveys, which I surprising found very useful. The companion usability.gov site was even more interesting as it looks well designed and also has useful information, which was a double shocked. It is interesting how perceived notions sometimes don't help us at all.

After gathering just five days of survey data, I only have 19 responses from active members, which is disappointing but still better than guessing or having no data. I wanted to explore creating a visualization of the data collected from the survey as I used a rank order to try to figure out what members like that we are cur renting doing. This is my survey data:

Rank	Book Club	Webiners	Workshops	Community Events	Social Events
member 1	5	2	1	3	4
member 2	5	2	1	3	4
member 3	5	2	1	4	3
member 4	5	1	3	4	2
member 5	4	1	3	2	4
member 6	3	2	1	1	2
member 7	2	3	1	3	4
member 8	5	4	2	1	3
member 9	5	4	1	2	3
member 10	4	1	2	3	5
member 11	3	2	1	4
member 12	1	1	1	1	1
member 13	5	3	1	2	4
member 14	5	2	1	4	3
member 15	3	2	1	3	5
member 16	4	3	1	2	5
member 17	4	3	1	2	2
member 18	3	2	1	5	4
member 19	3	1	1	3	2

So I want to creating a visualization of this data to know what is important to our members. I used a "rank order visualization" google search to see what I could find. I found a gem in one of the UX stack exchange entries, where a discussion of using column charts, pie charts, bubble charts and even Excel spark lines was suggested. I looked at another Stats stack exchange article which was a deeper explanation on using spark lines. Then I got a bit crazy and wanted to look up existing research on how to visualization my data as it just seemed like a old problem. I found this interesting IEEE article from GaTech on using a heat map. While exploring, I then wondered how people visualization Likert scales, which I did not use for my surveys but it is definitely related and maybe be helpful. I found this great article which I need to file and use in the future. I especially like this one:

I am also quite fond of this paper on correlating rankings and then realized I was getting a bit off track. I went to the site for my favorite graphing package called HighCharts to see how easy some of these could be achieved. I really like bubble charts but after looking at the data I realized that this is not the correct visualization to help me. Finally after a couple of minor diversions, I went to Apple Numbers to add the data and created a summary table of the counts of each ranking by type and came up with this simple column chart that tells me every I need to know:

I just look at the column chart and find the largest bars for each type and I am done:

1st - Workshops
2nd - Webinars
3rd - Community Events
4th - Social Events
5th - Book Club 

How to select a mobile prototyping tool

This week I needed to find the best prototyping tool to build a series of user testable interfaces on an iPhone. I have built several prototypes using Balsamiq but it was always in the context of trying to gather feedback from product owners on workflow thru the app design. It is a great tool as they supply templates for just about any user interface know to man on their Mockups To Go site. I like using this tool to capture my vision and to explore several alternatives. Using the Balsamiq templates, I can quickly see if the design will actually work. I also use the prototypes to test user scenarios so I know they work at least for me. If I cannot get thru the work flow navigating thru the app then there is no need to test actual users on the interface. Another side benefit of this type of prototype is to get general acceptance from the product owner. Whether it is used to get additional funding or to demo to potential customers as a sales aid, when working with entrepreneurs I find these visual prototypes are invaluable. The product owner is paying for a product and a prototype can definitely help them visualize what they are spending their hard earned money on. Of course there is nothing better than actual end user testing, but their time is precious also and should not be wasted with half baked prototypes that cannot pass a smoke test.

The best thing about Balsamiq is that it has two modes for creating an output clickable PDF. It can look either like a hand drawn sketch or a wireframe. Another nice feature is when exporting a PDF the output can be optimized for viewing (which is great for discussion of annotations recorded in document) or by shrinking the output to fit a page (which is ideal for printing the PDF to make hard written notes while in a conference room). The last feature that I find really useful is that the link hints are optional. For user testing you never want them to appear, but when in initial discussions they are really helpful for the product owner to see the intended user flow thru the app.

Since I was already familiar with Balsamiq, I started building a two page prototype by using Words with Friends app. It was an app I use all of the time and it has some interesting uses of standard iOS controls as well as some custom components. My intent was to see how long it would take to build the two screens including all of the visual treatments and the interactions between the two screens. I also need to use the standard iOS 7 look-n-feel. This is very easy for Balsamiq as the iOS 7 templates already exist at their site. The biggest unknown for me at the start was how the clickable PDF would work on my iPhone. The end result has to be a workable prototype that actual users can use so it cannot just look good it has to be interactive and useable.

1) Added iOS 7 controls inside iPhone device using Balsamiq template

2) Removed device template

3) Duplicated first page
4) Shifted content to right
5) Added settings screen
6) Added clickable links on vertical bars icon

 My first attempt at getting the clickable PDF on my iPhone was to email it to myself. When I opened the PDF on my iPhone, it was not the best user experience as the PDF was embedded in the email app  decoration and the links did not work. I tried both Yahoo! and Gmail and neither one of them were acceptable. I have both Dropbox and Goggle Drive, which worked by using the equivalent of a preview app on the iPhone. My next attempt was using an app called File Browser as it integrates with iTunes. When I connect my iPhone to my Mac, I can then drag the clickable PDFs to the File Browser app and that works as well. I needed to find a better way as I did not want to depend on DropBox, Google Drive or having the physical device attached to my computer.

After an hour of research I found an app called Documents by Readdle. It was a great find as it supports all kinds of network storage alternatives and I have absolute confidence that any iPhone used for testing will have access to one of these methods. The list is quite impressive: iCloud, Dropbox, WebDAV Server, Windows SMB, Google Drive, FTP Server, SFTP Server, SugarSync, Box, Office 365 Sharepoint, SkyDrive and CloudMe. Even better the app has settings on how to view a PDF by using the built-in iOS Viewer or the Readdle PDF Expert. This is the best find of the week as it is also free!

After getting that to work, it was time to switch to something completely different by using a tool I had not previously considered. I found a great list of prototyping tools written in July, 2013 and posted on Alan Cooper's web site. I am not a big fan of subscription services, mostly because I don't do prototyping full time. I am also not a proponent of becoming an expert in a single tool as that tool may become obsolete by the time I conquer it or a better one may come out and then switching will not be that easy. I spent time evaluating two tools. The first is called AppCooker but it has a big draw back as it only runs on an iPad. There is a similar tool called Blueprint. Both of these tools come with free app viewers with examples to try them out. It turns out they both did the standard iOS Clock app so that made it easy to compare them on the user interaction side. I was not impressed with either one enough to buy them on my iPad. For starters, why would I want to build a prototype on an iPad for an iPhone? Time to find another tool.

One tool that kept popping up in searches and blog posts was called Antetype, so I thought it would be good to study it. They have nine training videos on their web site so I watched them all to get a feeling for whether I would like to use it. It has many great features and I am sure you could build any prototype known to man using it, but with great flexibility comes great complexity. They also had a community and an impressive gallery on their site. I would be willing to invest time in this tool if it was my full time job, but since it is not I need to find something else.

One of my favorite speakers and writers is Luke Wroblewski, so I searched his site to see if he had any suggestions. Lo and behold, he suggested Keynote. Several years ago I used PowerPoint to quickly put together a linkable presentation but it was just so simple that I never considered using it again. It turns out that a company called Keynotopia has created templates for Keynote to do the same thing as I had done with Balsamiq. Besides having a great web site, there list of templates or themes as they call them is very impressive. Before buying the Keynote Bundle I tried build a couple of simple pages in Keynote with custom transitions. I typically don't like such things in a presentation as I find them distracting, but to simulate iOS page transitions, it seems like a perfect alternative. TI quickly found the best thing about using the Keynotopia templates as all of the iOS 7 components are vector drawings! The following screenshots show how close these are to the Balsamiq screens. It took about the same amount of time but that is good news as I have never used Keynote in this way before so I can had a learn how to best to set links and use the templates. The first tricky part was adding a clickable link that works on the iPhone. The best way I found was to add a transparent region around the vertical lines icon; otherwise, even with the lines being grouped together, the tapping on the iPhone did not work properly. I also found that using the Push transition was perfect to simulate the switch from one of these screens to the other. When on the first screen the transition was left-to-right and when on the second screen the transition was from right-to-left. Wow did that work perfectly and look great at the same time.

first screen using Keynotopia

second screen using Keynotopia

Since I am surrounded at work with great developers, I thought a third option would be to let one of them build the same thing using Apple's Xcode. All of the data would be static so I wanted to see how much storyboards could be used with the absolute minimum amount of Objective-C code. At the start I thought it would be nice to use only storyboards, but we soon discovered that in this case that was impossible. The biggest amount of effort was spent on getting the page transitions working correctly and also getting the second screen appear with the first screen partially exposed. This behavior used in many iPhone and iPad apps is not built into iOS controls and so must be manually created. I also did not want to bring in any other external libraries to help us. It was really an exercise in creating the very same interface and discovering which one would be the best way to deliver prototypes. The only real drawback to the native iOS app is that we would have to use a tool like TestFlight to deploy the app outside the Apple store for user testing. The best thing of all about the using Xcode to build the prototype is that scrolling to see the rest of the contents in the first screen just works as expected, but in the Balsamiq and Keynote prototypes, this behavior would have to be implemented as separate pages. It can be done, but is more painful and time consuming.

first screen using Xcode

second screen using Xcode

As in everything I do, there are tradeoffs to be considered. I definitely prefer Keynotopia to Balsamiq as the iOS 7 templates are exhaustive and look just like a real app. I like how easy it is to create transitions in Keynote that look just like using a real app. I definitely like using the Readdle app as I don't need to deal with locating the device ID to enter into TestFlight as is used to deliver the Xcode app. Some of the things that the developer did to get this to work were just not reasonable for me to know and remember since I don't do iOS development, so that is definitely a drawback. For now I am going to se Keynotopia if I have to build a prototype by myself and if I have a developer helping me then Xcode wins hands down.