Friday, January 15, 2016

Creating a Software Licensing Solution with LiveCode

The final development stage of my video analysis tool is coming along nicely. I hope to wrap it up in the next few days in order to do some final beta testing before I release version 1.0 as a commercial product. I keep joking that I plan to price it at the cost of a breve expresso, but I think that is about the right price. I actually plan to give it away to a lot of colleagues and their students, especially here at UGA. (Disclaimer: I was not paid or compensated in any way by the University of Georgia to create this tool.) But, I do think there will be a small market for this tool and I'm looking forward to the entrepreneurial experience that awaits. Just going through all of the steps to get this thing to market and figuring out how to accept payment and provide customer service will be a great learning experience for me. (I considering submitting to one of the available online stores, such as the Mac App Store.)

These thoughts point to the need to produce a free version of the tool that prospective customers can access to evaluate to make sure it serves their needs well. If it is a good tool for them, then I hope it will persuade them to purchase the full version. Likewise, I would like an easy way to give the tool to colleagues for use in their classes. Now, I could produce several different, standalone versions of the tool where each serves a distinct purpose. But, that would be complicated and a lot of work. So, I've come up with a solution that allows me to create and maintain one product that serves all purposes. Now, I'm sure there is a great literature out there somewhere that would explain various approaches or algorithms for doing this. But, true to my design spirit, I just forged ahead and invented my own approach.

Lloyd's Licensing Approach


The approach I used relies on one new global variable that I titled "varFullVersion" that is either true or false. When true - as the name suggests - all options and functions are available to the user. When false, a few critical options or functions are turned off. I have set it to false by default, so the free version is triggered upon start up unless the program finds a certain value in a certain file stored on the user's computer.

Deciding on which options or functions to turn off was an interesting design decision. There is a balance to be struck between giving users enough functionality to be able to evaluate the tool, but not enough to keep them from wanting to purchase the full tool if they find it useful. I settled on disabling two main functions. First, the free version only allows the user to work on one project. If you want to work on another, you have to first delete that project before beginning another. I also removed the capability to export source files. Not doing so would have created a loop hole allowing people to use the free version - albeit inconveniently - pretty much as the full version. They could begin a project, then export the source file and delete the project, only to import the source file later to continue working on the original project. I should probably turn off other functions as well (e.g. ability to import source files), but I'd rather error now on the side of giving people a good opportunity to check out the tool.

How to Integrate Licensing Codes


The next obvious question is how to toggle the varFullVersion variable to true or false. The concept is simple - people download the free version, so the default value is false. Then, if they decide to purchase the full version (or if I want to give to them), I need to give them some code that "turns on" the full version. If you have ever downloaded trial versions of commercial software, you know just how common this is. You download the trial version and if you then purchase the software, you are simply sent a code to unlock it.

One way to do this would be to hard code into the standalone alone a secret code that, if entered by the user, would unlock the full version. But, I wanted to have a little more control than that. I wanted to have a list of codes that I could give out and manage. For example, say I have a colleague who is teaching a course and wants to start using the tool next week with his students. I wanted a way to give that colleague a unique code to share with his students that would be "active" for a short period of time, just long enough for his students to download the tool and activate it. But, I didn't want his students to give out the code to friends and family to activate the tool later. I needed a way to activate or deactivate a list of unique codes at will.

Storing Codes on the Internet


Fortunately, in some of my other LiveCode projects, I have learned how easy it is to use information from text files stored on the Internet. I really like this approach because it saves me from the hassle of creating a database backend for storing simple information. So, I have hard coded into my tool a web address that points to a simple text file containing a list of codes. (Sorry, I won't be giving out that URL here - that would defeat the "secrecy" needed for the approach!) Here is an example of what the file looks like:

 87-93-87-22-44, the current commercial license code  
 bob7395, special code for Dr. Bob to use the tool with his class  
 stop, psych101vat, special code for the introductory psychology courses  
 vatforfamily, a special code just for sharing the tool with family and friends  

Each line has a list of items separated by a comma. The first item is the code. All other items are ignored. Notice that the code in line 3 is "stop." I've simply programmed the tool to ignore the word "stop" as a code. So, if I want to turn off a certain code for awhile, I simply add this word as the first item in that line. If I want to reactivate the code, I remove it. I can also simply substitute a new code for that group at any time. The program reads in all of the lines and will allow any active code to unlock the full version of the tool.

I should mention that I did program in a "back door" code directly into the program. So, if I ever need to unlock the tool for whatever reason (e.g. the Internet is down), I can do so.

How to Save the Codes


As I mentioned, I have the variable "varFullVersion" set to false as its default when the video analysis tool is launched. Obviously, the first things the program does is check to see if the person has previously unlocked the full version. How is this done? In short, I save a secret code stored in a file I won't name on the person's computer. It works kinda like a cookie. Most commercial software program access a special "preferences" folder on the user's computer to store these sorts of files. Maybe I do too, or maybe I don't - I'm not giving out those details here. The idea is simple though, if this secret file and code are found, then varFullVersion is immediately set to true within the first second after launch. Otherwise, the value remains false the free version is provided.

An advantage of using this approach is that if the user gives a friend a copy of the tool after they unlock the full version, they won't know anything about this stored file. So, when the friend launches the program, the free version is triggered.

Final Thoughts


Is this the best way to build a licensing function into a software program? I really don't know, but I doubt it. I'm actually quite sure there are way more sophisticated ways of doing this. But, with a zero budget, this approach seems to work based on my current knowledge of LiveCode. Of course, if my video analysis tool sells a million units, I may hire a real programmer to improve on this design.



Saturday, January 2, 2016

Back to Work on Lloyd's Video Analysis Tool With a Focus on Graphic Design

It's been just over a year since I last wrote about my video analysis tool. I've spent the year in beta test mode showing the app to various groups and giving the app away to anyone who had an interest in using it. My only condition was that they would give me feedback. As of today, a total of 54 people have signed up to be "official" beta testers. (If you would like to be one, just go to my video analysis tool's website and click on the link at the top of the page.) The feedback I've received has generally been very positive with most of the criticisms and suggestions for improvements stemming from the Windows version of the tool (more about that later.)

I've also spent the year using my video analysis tool. I have found it most useful for creating transcriptions of the videos I create for teaching. In fact, I'm seriously thinking of creating a standalone app just for the transcription tool itself.

I'm convinced that my video analysis tool is worthy of greater things, so I've begun a serious effort on producing a significant update. I'm beginning with a focus on improving the tool's graphic design.

If you are one of the four people who read this blog, then you know that I've been very honest about my lack of graphic design ability. You also know that I never let it bother me, nor do I let it get in the way of my prototyping. But, every now and then I get some friendly feedback from people who really do find my stuff to be ugly. I usually just smile and remind them "it's only a prototype." This is a sincere answer because I rarely spend any serious time on graphic design. My goal is on creative ideation to build a working prototype of an original design. However, I have a few colleagues around the country with a refined sense of graphic design who are on the record saying that they simply won't use an app or web site that they find visually offensive. If I'm in the audience, I always get the sense that they then look at me from the corner of their eye.

The bottom-line is that I know I have to improve the graphic design of my video analysis tool if I want people to consider using it and (gasp!) consider paying a small amount to purchase it. (Yes I'm thinking of selling it, but with a price about equal to the cost of a breve expresso at Starbuck's.) Given my budget of zero dollars, I can't hire someone to do this work and I don't have the heart to ask some of the talented graphic designers I know to do it for free. Plus, I really wanted the challenge.

Here is my targeted benchmark for success: No one finds the app visually offensive.

It's not that I don't know anything about graphic design. Heck, in my "classic" (i.e. old) book Computers, Graphics, and Learning (1994), I even wrote about graphic design (p. 195-196):
... there are some generally accepted issues and concepts related to visual layout that are relevant at this point. Even the most specific design principles can be traced to one of four broad categories of visual design and layout: simplicity, unity, emphasis, and balance. In a sense, these principles aptly summarize much of the previous discussion of frame and procedural protocol. All four categories can be supported and described on the basis of human perception and information processing. For example, visual layout should take into account a person's abilities and limitations in selectively perceiving the most important information in a given display. All information coming from the environment will be competing for a person's limited attention. Therefore, a display should be designed to maximize the chances that a person will notice the most relevant quickly; it should also be able to sustain user attention over a period of time. When combined with rapid prototyping procedures and a lifelong hobby of "software watching," these principles can help guide beginners in designing effective screens.
The principles of simplicity, unity, emphasis, and balance are a good guide, though if you don't have any talent (like me), then you can only expect so much. A very weak area for me is color. I tend to use color in the most simplistic ways and I rarely use anything but pure saturated colors. I usually start with the colors of nature (e.g. green, yellow, and brown, with dashes of red), though when I'm knee deep into prototyping I usually just choose almost any new color when another one is needed. As I prepared to improve the graphic design of my video analysis tool, I knew I had to do more than just "try harder." And, it's not that I don't appreciate good graphic design - I think I "know it when I see it."

Before I share my strategy, let me show you the current draft of my tool's two main screens - the title screen and the video analysis screen (click on either to see them actual size).

Video Analysis Tool Title and Analysis Screens: 



For comparison, here are the previous versions: 



Lloyd's Guide to Graphic Design for Those with Little or No Talent


OK, I'm not saying my current design will win any awards, but I hope we can all agree that the changes mark a dramatic and certain improvement. To do this, I followed a simple strategy that I think others also without graphic design talent may find useful.

Step 1: Do a Google Search


I know, genius. It turns out there are lots of talented graphic designers out there willing to share their expertise with you. My starting point was finding a suitable color palette. I did a search using phrases such as "examples of color palettes" and found some very good advice. Here are the two sites that probably gave me the best information and inspiration:

Step 2: Choose the Mood You Want to Project


On some past projects where I've been fortunate to have a professional graphic designer on board, they would typically ask about what mood or first impression is desired for the project. I think this is a good place to start thinking about graphic design. I think in my case I wanted something that felt "professional and productive, yet enjoyable." I didn't want "cutesy," "toyish," or "cartoonish." 

Related to mood is the choice of an organizing framework, which often times equates to using a metaphor. For example, at one point months ago I toyed with the idea of using a medical metaphor for the project - you as a doctor "diagnosing" your video. Another was "video detective" where you are "sleuthing" the meaning of a video. If I had made a choice such as these, then this would have pointed to the use of graphical objects such as stethoscopes or microscopes, a magnifying glass, a Sherlock Holmes pipe, and the like. I obviously decided not to use any overt metaphor for this project, but you get the idea of how it would influence the graphic design.

Step 3: Choose and Stick to a Color Palette


Once the mood and organizing framework is chosen, the next step is to choose colors and graphical objects to implement it. This is where a talented graphical designer can do magic to draw backgrounds for context, characters, and the like. For the rest of us, we might have to use clip art. Either way, a key place to start is to choose and stick to a color palette.

The great thing about the sites above is that they give the color palette for each design in hex notation. This allows me to match the colors exactly. Here were the two examples that really caught my eye:


I've not included a screenshot of either here given that I think this would be a copyright infringement, but you can click on the links yourself to see them. If you do, I'm sure you will see how my title screen was inspired particularly by "Pixels & Aromates." I thought the gradients of brown were warm and friendly. And, for some reason, they evoked a pleasant look of a chocolate milkshake. (Way back when I was trying to come up with a name for this app, I had toyed with the idea of "video milkshake" for reasons I don't remember.) I also really liked the red hue that was used. I decided on using that red for oversized buttons, which may have been too much red. But the color combinations are pleasing to my eye. I made these buttons round to get away from the original boxish look. I also decided that the option to import a source file did not deserve equal prominence, so I de-emphasized that button.

I needed more colors for the analysis screen, so I again consulted the above web sites for guidance. For example, I wanted to call special attention to the video clip controls in the upper right-hand portion of the screen. I settled on two shades of muted orange.

On the analysis screen I wanted to set apart the two save buttons and the one delete button. I used the time-honored (and probably western) tradition of green means "go" or "safe" and red means "stop" or "caution." I also physically separated these buttons to prevent any accidental clicking. (However, I am careful in my user interface design to give adequate warning should an inadvertent click occur.)

One last detail worth mentioning is my use of the golden ratio on the title screen for placing the slightly darker brown band at the top. The band itself divides the large space nicely and the golden ratio (total height divided by height of bottom portion of the screen) of 1.161803 determined how thick to make it.

Step 4: Use the Principles of Simplicity, Unity, Emphasis, and Balance to Create the Screen Design


Probably the biggest change I made was to create a toolbar at the top of the analysis screen using the darkest shade of brown to group navigational buttons and other options. Previously, I had all of these buttons scattered around the screen. The haphazard way these were initially placed mirrored when I created these various options as the prototype of the app was built. I feel this toolbar organizes all of these options very effectively. The other advantage of the toolbar is that I was able to reclaim a lot of screen space. I can now fit a total of 40 tags in the "Quick Tags" window, instead of 24.

I also visually grouped the four main parts of the analysis screen to achieve unity. As you can see from my before and after examples, I really did not make any major changes to the placement of these four areas. But, I made some small, but important design updates. First, I used shades of brown with a thin black border to define each group area. LiveCode has some built in graphic effects, such as drop shadow. I like how this gives the screen some depth. I also made sure everything lined up well for a sense of balance.

As already mentioned, the use of greens, reds, and orange also provide effective emphasis of key areas and functions.

Other Useful Tools


Although you can script colors into LiveCode objects using either hexidecimal or RGB notation, it appears you can only use RGB to "hard code" colors in the inspector window. So, I used this handy Hex-to-RGB converter:

http://hex.colorrrs.com/

My photoshop skills are also minimal, so I didn't want to spend time creating my own buttons. Instead, I used this web site to create prefabricated buttons:

http://dabuttonfactory.com/

I did use photoshop to create the stylized text on my home screen, but here is also a web site I found as a fall-back tool:

http://cooltext.com/

Although I chose orange and green hues that were part of existing palettes shown in the above web site examples, there are also lots of color picker tools out there to help when choosing new colors, such as the following:

http://www.w3schools.com/colors/colors_picker.asp

Note about the Windows Version


I mentioned at start of this blog post that most of the negative feedback from my beta tesers has come from the Windows version of my video analysis tool. Although it's great that LiveCode allows for exporting desktop apps to Macintosh, Windows, and Linux, this really is designed as a Macintosh app. Because this app involves video, a Windows user must have QuickTime installed on their computers. Even then, there are problems that have been reported that are simply a mystery to me. I have simply not been able to sufficiently troubleshoot problems on the Windows side. So, I'm seriously thinking of removing the Windows option, at least until I finish with the Macintosh version.

Final Thoughts


I'm very happy with these graphic design improvements, even though I know I'll continue to tweak the design over the coming weeks. I also enjoyed the process, as time-consuming as it was. If I had the money, I would have much preferred turning this task over to a professional graphic designer. But, maybe this shows that even someone with very limited ability can follow a graphic design process to at least meet the criteria of not making people nauseous when they look at an app.

Of course, if there are any talented graphic designers out there who want to redesign my app for just the fun of it, please drop me a line.