The Scriptures 1.0.4 for iPhone / iPod Touch is now available for download. This release contains a couple of bug fixes and new features.

What’s New

One feature that has been consistently requested is the ability to navigate between chapters. There are now buttons on the title bar that allow you to do just that. These buttons also allow you to quickly navigate between search results.

I’ve also added the ability to change font styles. Though I personally think The Scriptures look better in a serif font, a few people have asked for the ability to change to a sans-serif view. You can now make that change in the application settings.

Finally, I also added the really nice icon that Gaige Redd has contributed. I really wanted to keep the Angel Moroni theme and Gaige did a great job with it.

There were also a few bug fixes, which you can read about in detail in the changelog.

What’s Next

There are three things that I’m currently working on and hope to be done with soon:

1. More Content - Everyone wants more content. I’m not sure what will be added when, but I can tell you that the first things I want to include are chapter headings, footnotes, and study helps.
2. Bookmarks and Annotations - Coming very very soon. The tricky part with this isn’t the coding. It is trivial to mark spots in the scriptures, or to create a list of saved locations to navigate to. The tricky part (as with any new feature) is the UI Design. On a device like the iPhone especially it is critical to get the UI right. I’ve been working at this and I think that you will like the UI design that I’ve settled on.
3. Localizations (aka Translations) - I have gotten so many requests for translations as well as offers for help, and this is a priority item that I want to get done soon. (More on this below)

Calling all Localizers

In the software development world implementing an application in a new language is commonly called localization rather than translation for a couple of reasons.

First of all you aren’t just translating the content, you are also converting the UI to work as expected in the locale where the new language is spoken. That means things like dates and currency should be appropriately converted.

Also, localization (especially of the UI) doesn’t just mean translating the commands word for word with a dictionary. Just as in English, every language has certain idioms and conventions that are used in technology that go beyond a simple translation. For example look at this screenshot of iTunes in its Brazilian Portugûese localization:

Notice how the “View” menu is localized as “Visualizar” which is literally “To Visualize” rather than “Vista” which is the noun for view. Also notice how the “Store” heading is localized as “Loja” which is a direct translation for store, but that “iTunes Store” is left alone. Also, “Ringtones” is localized as “toques” which literally means the plural noun “touches”.

Why am I telling you all of this? Because I need your help. While I am fluent in English and Brazilian Portûguese because of the time I spent in Brazil, there are many other languages that I would like to do localizations for. (And even for Portûguese I don’t know all of the necessary technical conventions needed for the UI localization).

Desired Qualifications

If you would like to help, here are the qualifications:

1. You must be a native speaker or have near native fluency in the language you want to help localize.
2. You must have experience using software in the language you want to help with. (So you’ll know those conventions I mentioned above).
3. You must be willing to install buggy beta software on your iPhone or iPod Touch.
4. You must know how to find your iPhone’s Unique Device Identifier. (I need this in order to make the beta software run on your device)
5. Previous experience as a beta tester/localizer is preferred, but not necessary.
6. You should know how to write a good bug report.
7. You must be willing to do this for absolutely no compensation.

The Localization Process

The localization process will basically work like this:

• You will email me with your name, the language(s) you would like to assist with and the UDID of your iPhone or iPod Touch.
• I will email you a list of terms from the user interface that need to be localized.
• You will email me back a list of localizations for each of those terms in the form: “English Term: Localized Term”
• I will make the necessary updates in the application to incorporate the localization.
• I will send you a beta version of the software containing the localization along with instructions on how to install it.
• You will install the beta software and test it, paying special attention to the localizations.
• You will send me reports for any bugs that you find.
• I will fix the bugs that are reported, create a new version of the beta software, and email it to you.
• You will install the new beta software and test it, paying special attention to the localizations.

Once everyone is satisfied that there are no problems with the localization, the update will be submitted to the App Store for distribution.

If after reading this you are interested in helping out, you may send me an email with your name, device UDID, and the language(s) you would like to assist with. I can’t guarantee that every language will be done, nor the order that I will go in, but I will do as many as I can that the Scriptures are available for in digital form.

You may email me at: lee <dot> falin <at>gmail <dot> com

I just finished submitting version 1.0.4 of The Scriptures for the iPhone/iPod Touch for review. I’ll post an update when it is approved. For more information on what’s new in this version, see the changelog.

The Scriptures for the iPhone and iPod Touch version 1.0.1 is now in review status at the App Store. You can read about the changes here.

On App Store Reviews

One thing I’ve noticed about the reviews that the application has received is that they are all pretty favorable, which I’m grateful for. The ones that aren’t favorable (which are all one star reviews), all have a common theme. Not one of them is a review of the application itself, but of the religion that the application is designed for.

I should be used to people criticizing and mocking my religion, but what always amazes me is how members of other Christian churches feel it is their duty to expose us as some radical group of wacko impostor Christians simply because our beliefs regarding the Savior are different than their own.

This isn’t a new practice among Christians, but as illustrated in Luke chapter 9 it is one that we should all know better than to follow:

49 And John answered and said, Master, we saw one casting out devils in thy name; and we forbad him, because he followeth not with us.

50 And Jesus said unto him, Forbid him not: for he that is not against us is for us.

Apple handles these types of reviews in the App Store by providing a “Was this review helpful” feature, which other people can answer yes or no. Since by default the reviews are sorted by most helpful, these types of irrelevant reviews tend to get pushed towards the bottom.

On “Competition”

Something else I’ve noticed in the App Store reviews is a tendency for people to compare The Scriptures application which I developed to the one developed by Michael Jensen. Such comparisons between similar applications are natural, however there a few things regarding these comparisons that I feel a need to comment on.

First of all my application is not in competition with Michael’s. Compete is defined as:

verb: strive to gain or win something by defeating or establishing superiority over others who are trying to do the same

I am not striving to gain or win something, nor am I trying to defeat or establish superiority over Michael’s app. When I started writing The Scriptures, there was no LDS Scripture reader for the iPhone yet available. I wanted one, so I decided to write one. While I was writing one, Michael’s was released. It takes a bit of time to design and develop an application. (Not to mention how long it takes to get one through the App Store review process), so don’t think that I saw Michael’s app and said to myself, “Hmmm, I think I’ll write a free version to compete with this.”.

This brings me to my next point, some reviews that I have seen on both my (and recently Michael’s) app, have criticized Michael for charging money for something that many people believe should be given away for free. While I don’t charge for my application, having run a software business for some time, I can’t begrudge someone for wanting to charge money for their work. Michael has stated that he contracted with a developer to write the application. This of course costs money. We don’t know if it was an hourly rate, a one time contract, if there was a retainer fee for updates, if royalties are involved, etc.. On top of that, there is a cost involved to just getting an application in the App Store once it is written.

It isn’t fair to Michael to pass judgement on him when we don’t know the particulars of the financial details involved in his situation. We shouldn’t forget the work he did to make ReadScriptures.com available for free (which must be costing Michael some of his personal money every month just in hosting fees). Above all we should remember that Michael is a son of God with a wife and children that love him. That alone should command our respect.

</soapbox>

It has given my great joy to write this application and see people receive it favorably. In the latest release, I tried to incorporate as many suggestions from users as I could given my time constraints. I hope to add even more great features in the future, so please keep your emails coming. It’s nice to hear from users that are enjoying some feature that I worked hard to design and implement. Just to give you an idea of things to come, the next point release should include:

• Scripture marking support.
• Annotations (note taking).
• Inter-chapter navigation.
• The ability to change to a sans-serif type font
• (Hopefully) footnotes

If I am able to include more content, I will. As I have already told many of you regarding this, some of those items that I want to include are under copyright from the church and I can’t legally put them into an application for distribution without their permission, hopefully however, that will be resolved soon.

Finally some people have asked if they could donate to support this effort. The answer is thanks, but no. The Scriptures are and will remain free. As I mentioned on the project page, if you like the application so much that you want to donate something, instead of sending me money, make a donation to the Church’s Perpetual Education Fund to help the next generation of application developers (among other careers).

Thanks again for everyone’s support, as always Please send all bug reports / feature requests to me via email:

lee <dot> falin <at>gmail <dot> com

I have just uploaded my first iPhone/iPod Touch to the App Store!

The Scriptures for the iPhone/iPod Touch

It is currently pending approval. I’ll post a link to its appstore page when it comes available.

In the mean time, head over to its project page to check it out.

Developing for the iPhone is an interesting process, there is a lot that is different from developing applications for the Mac, not just in terms of the standard controls, but also in terms of how you think about the project design, and program flow.

If the NDA ever gets lifted on the iPhone SDK, I’ll talk more about those differences.

Update: The Scriptures is now available for download.

A couple of articles came out recently regarding the quality of good UI design and since this is an area that I’m relatively passionate about, I couldn’t resist adding my voice to the mix.

Last year I did a presentation for a course I was taking on the state of user interface design in the realm of scientific software. My study was based on two papers:

Nielsen, J. and Landauer, T. K. 1993. A mathematical model of the finding of usability problems.1

Javahery, H., Seffah, A., and Radhakrishnan, T. 2004. Beyond power: making bioinformatics tools user-centered.2

To start out I asked those present to look at the user interface of a relatively popular and extremely powerful piece of software used for molecular docking. (which shall remain nameless). Those in attendance were relatively familiar with the subject matter that this software dealt with, and at least one was an expert in the field. I asked them how they would go about performing a few relatively simple tasks. No one could figure it out. The controls were non-intuitive and the interface didn’t adhere to any standard UI design principles.

I then showed them the interface to a relatively popular photo management program:

I then asked them how they would go about editing a photo or sending a photo to someone via email. Of course the answers where obvious to everyone. Now is this because the Apple engineers were geniuses and the scientific software developers weren’t? Of course not. You don’t write extremely powerful and useful scientific software by being dumb.

UI Design Research

In their research, Nielsen (considered by many to be the expert in usability testing), and Landauer found that you only need to test your user interface design with 5 users to find over 75% of usability problems. Just 5 users! So if it so easy to find problems in UI design, why do we still have such lousy user interfaces in scientific software? Nielsen and Landauer found that a simple model could quantify the cost to benefits ratio of usability testing. The potential payoffs are substantial:

The model basically figures in two factors:

1. The cost of each test user
2. The savings to be realized by improved usability (i.e. lower support costs, fewer incremental releases to fix UI problems, etc…)

Unfortunately this model breaks down in the realm of scientific software. Here is my hypothesis as to why that is and why it’s likely to continue if nothing changes:

Lee’s Scientific Software UI Hypothesis

A large portion of scientific tools have poor user interfaces due to a combination of the following factors:

1. There is usually no funding for user interface testing.

The fact is that most funding organizations aren’t interested in paying for usability testing. Consequently it doesn’t get done.

2. Tool-based papers aren’t evaluated for good user interface design during peer review.

Tool based papers (like other scientific papers) are evaluated for merit and accuracy (as they should be). They are not however evaluated based on UI design principles. Changing this alone would stop the deluge of poorly designed user interfaces in scientific software.

(For those of you who aren’t familiar with this process, scientific papers (unlike highly-opinionated blog entries like this one) go through a process called peer-review where they are evaluated for their merit and accuracy. This (usually) helps to filter out work of lesser quality.)

3. Most people writing these software tools either don’t know what good user interface design looks like or don’t care.

In my experience I have found that there are usually two types of people designing scientific software in the life sciences field. CS grads who have lots of training in designing algorithms but usually no training in UI design, or life scientists who have neither.

This may be an over generalization, but in my experience (and I’m a CS grad), CS grads don’t know how to design good user interfaces. It’s not our fault, these things simply aren’t taught in most CS curriculums. We can optimize O(logn^2) algorithms in our sleep but we often seem to have trouble with basic UI design principles. Either we don’t know about them or we don’t care enough to use them.

4. There are no savings to be gained in improving the user interface.

This is the big one. There is exactly one payoff for most people in the realm of scientific software (aside from altruistic ones of course), and that is publications. If I publish a paper based on a software tool with a really good and well tested UI design, it counts just as much for me as if I publish a paper based on a software tool designed by a bunch of blind monkeys. (No offense to blind monkeys intended).

Conclusion

So despite the fact that studies (peer reviewed studies mind you) have shown that only a very small number of testers are required to find usability problems, the cost to benefits ratio for scientific tools developers is still unfortunately too high to justify real user interface testing and until that changes we’re going to continue to be stuck with the quality of user interfaces that are currently typical of scientific tools.

1. Nielsen, J. and Landauer, T. K. 1993. A mathematical model of the finding of usability problems. In Proceedings of the INTERACT ‘93 and CHI ‘93 Conference on Human Factors in Computing Systems (Amsterdam, The Netherlands, April 24 - 29, 1993). CHI ‘93. ACM, New York, NY, 206-213
2. Javahery, H., Seffah, A., and Radhakrishnan, T. 2004. Beyond power: making bioinformatics tools user-centered. Commun. ACM 47, 11 (Nov. 2004), 58-63

Acorn is an awesome image editing program from Gus Mueller at Flying Meat. The reason that I like it so much is that it is simple to use, but is still very powerful. It has all of the features that I need to do everything that I would would do with Photoshop, and I don’t have to pay ridiculous amounts of money to buy it.

To show just how easy it is to use Acorn, I’m writing up a series of tutorials that will show how to do some of the common things that people do in Photoshop, but using Acorn.

The Product Fade Effect

The first effect that I’m going to walk you through is the product fade effect. Everyone loves the product fade effect. There’s just something about seeing a beautifully engineered product sitting on a reflective surface that just makes you want to buy it. Our goal is going to be to create this image:

Doesn’t that fade at the bottom of the image just make you want to go out and buy an iPhone?

So let’s see how you can create equally tantalizing product images.

Step 1 - Load the Product Image

First open Acorn and create a new Document [File->New or Command-N]

You can set your image dimensions to whatever you want. I always set mine a bit larger than I need and then crop it down to the right size later. It’s important that whatever you select for your background color is going to work with your product image. The product image that I’m using has a white background, so I set my document background image to white as well.

Once your document has been created, open your product image file [File->Open or Command-O].

Select the document with the product image and copy the image [Edit->Copy or Command-C] and then select your new document and paste in the product image [Edit->Paste or Command-V]. Acorn automatically puts the pasted image into its own layer.

Step 2 - Position the Product Image

Next we need to move the product image up towards the top. You may not need to do this depending on the size of your image. This is easily done using the Move tool.

Click on the product image to select its layer and then click the Move tool or press V.

Click and drag on the product to move it towards the top of the image. This will give you space at the bottom for the faded reflection.

Step 3 - Create the Reflection Image

Now we want to create the copy of the product image that we will use for the reflection. There are a couple of ways to do this, and how you do it will depend on what your product image looks like. My product image has a large white background that I don’t want my reflection to have. So I need a way to select my product image independent of its background. One easy method to do that is to use the Magic Selection tool. If your product image doesn’t have a background, you can skip this part.

Click on the product image to select its layer and then click the Magic Selection tool or press W.

The “Wand tolerance” setting tells Acorn how sensitive to color it needs to be in making the selection. The higher the number, the less sensitive the tool is to slight changes of color. Here I’ve set my “Wand tolerance” setting to 100. Your value will differ depending on how different your product image color is from its background.

Click on the background of the product image. The magic wand tool should select everything but your product, the little dancing dashes will tell you what you have selected. (Again you may need to experiment with the Wand tolerance setting. If your selection isn’t right and you want to try again, you can get rid of your selection using [Select->Clear Selection or Command-D]).

Now this is the exact opposite of what we want to select. We have selected everything but our product and what we want is to select only our product. So next we need to invert the selection [Select->Inverse or Command-Shift-I]. The astute reader may wonder why we didn’t just select the product in the first place. The reason is that most of the time your product image is on a solid background color. Selecting a solid background color can usually be done in a single step with the magic selection tool, whereas selecting the product directly usually takes multiple steps using one or more of the other selection tools. This takes a lot longer and can drive you insane.

Once we have the product selected we want to make a new layer with just our selection [Layer->New Layer With Selection or Command-J].

Step 4 - Position the Reflection Image

Now we want to move the reflection image into position. The first thing we do is flip it upside down. Select the reflection layer that you just created and then flip it vertically [Layer->Rotate->Flip Layer Vertical].

Now move your upside down product image down to directly underneath the original product image using the move tool. You want the two images to line up just right.

One way to insure that lay line up is to move the image using the arrow keys by clicking the image and pressing down down down… a zillion times until it is in just the right spot. A faster way to do this is to use the handy grid feature [Image->Toggle Grid or Command-'], (you can adjust the grid size in [Image->Grid Settings...]) which then makes it easier to line up the layer using the mouse.

Step 5 - Fade the Reflection

This is where the real power of Acorn comes into play, it’s use of filters. There are just a ton of filters that you can apply to your image. We’re only going to need one to create our product fade effect though.

Select you reflection layer (the upside down one) by clicking on it and create a Linear Gradient Filter [Filter->Gradient->Linear Gradient...]. The Apply Filters window appears with the Linear Gradient Filter set to its default settings. These settings will obviously need to be changed.

If you mouse over the image preview window you will see two orange points appear, these are the points that define how the gradient is spread out. The way the linear gradient filter works is by drawing an imaginary line between gradient point 1 and gradient point 2 that extends on to the ends of your image. Everything before point 1 it paints color 1. Everything after point 2 it paints color 2. Everything in between the the two points is a subtle gradient between color 1 and color 2.

To get our desired effect, we’re going to set color 2 to be completely transparent. To do this, move the little opacity slider next to Color 2 all the way to the left. This will cause the gradient between the two points to be a blend of color 1 (which I leave white here, you will want to set to be whatever your background color is) and transparent.

Next you need to move the gradient points into the right positions. Click and drag the points so that point 2 is right at the top of your reflection image and point 1 is directly under point 2 at the position where you want the fade to be complete. You can also use the text boxes on the right to enter the coordinates of the points directly.

When you have your points lined up just right, click “Apply” to see the final result.

Conclusion

So in just 5 steps using Acorn you were able to create your very own product fade image that you can use to entice thousands and thousands of buyers.

Several others have mentioned it already, but Brad Wardell wrote a great article about game development and piracy.

This is my favorite quote:

The reason why we don’t put CD copy protection on our games isn’t because we’re nice guys. We do it because the people who actually buy games don’t like to mess with it. Our customers make the rules, not the pirates. Pirates don’t count. We know our customers could pirate our games if they want but choose to support our efforts. So we return the favor - we make the games they want and deliver them how they want it. This is also known as operating like every other industry outside the PC game industry.

As you may have already heard, Decimus Software has acquired Polarian.

This sale has worked out wonderfully. Benjamin and his team at Decimus are a really amazing group of people to work with. I am grateful for all of the inquiries that I received and apologize to anyone that I couldn’t get back to personally.

Selling was difficult for us for a lot of reasons, starting Polarian from nothing and bringing it to where it was has been an amazingly fun process. I have learned so much, about software development and business in general.

One of the best things about this deal though, is the fact that Decimus already has a solid reputation in the mac community. Knowing that the group buying Polarian had experience not only programming great mac software, but also running a successful customer-focused business made the decision much easier.

In case you didn’t read the press release, Decimus is having an introductory “50/50″ promotion to celebrate the acquisition. Through the 23rd of March, you can use the coupon code FIFTYFIFTY to purchase Screen Mimic for $50. Even cooler, is that owners of competing products can use the coupon code FIFTYFIFTYUPG to get a competitive upgrade discount of 50%.

Update++

Good news to anyone still interested, our potential buyer has had to back out, so I’m once again considering offers. leefalin@polarian.com

Update

I’d like to thank everyone who showed an interest in Polarian. At this time we have found a buyer and are no longer considering other offers. Thanks again to all those who inquired.

The Reason

When I started Polarian back in 2005, it was with the hope that one day Polarian would be the sole source of income for our family. As 2006 rolled around, Polarian was not yet fulfilling that dream and we made the decision to return to graduate school and pursue my other lifelong dream of being a professor and teaching at the university level.

Throughout 2006 my research still hadn’t really picked up speed and so I had quite a bit of free time. I continued to devote some of that time to further development of Screen Mimic. In 2007 this development came to fruition as Screen Mimic 2.0 was released. From there Polarian’s revenue grew exponentially and went from being a hobby income to something that could in fact fully sustain our family. We started making plans for Screen Mimic 3.0 as well as a new software application that I believed would do even better than Screen Mimic.

During that same period of growth, my research project was also finalized and became much more demanding. As 2008 started it was clear that we could no longer pursue both dreams, so it came time to choose between them. From the title of this entry it should be obvious which one we chose.

Making this choice was difficult for many reasons. We started Polarian from scratch, a blank screen and an idea. We actually began as graphic design company and started writing Screen Mimic after I couldn’t find a screen capture application for the mac that output to Flash format. Since I was in fact a lousy graphic designer, we shifted our efforts fully to Screen Mimic’s development.

After countless hours of hard work we released Screen Mimic 1.0, then 1.2, 1.5, 2.0, etc… Our sales were so high that it no longer made sense to use a third party payment processor so we even developed our own online store.

It has been an amazing process and I have learned so much by it. The Mac developer community is an amazing group of people and I am thankful for all of the support and knowledge that I have gained from them.

The Details

So what does that mean for you? Well it means that you, my faithful reader, now have the opportunity to purchase a complete turnkey software company that is currently earning substantial revenue.

The sale includes:

• All of the source code for Screen Mimic and all rights pertaining to it.
• An online store setup to take payments via credit card and PayPal, (though you’ll need to set up your own merchant account with your bank if you want to use it, and your bank would have to use the YourPay API). This isn’t necessary of course because Screen Mimic is setup to use license keys generated by Kagi as well.
• The source code to the fledgling Screen Mimic 3.0, along with my insider thoughts of where I think that the screencast market is heading.
• The source code to another software product that is 50% complete which I think will do even better than Screen Mimic.
• The professional designed icon for the above unnamed software product that was designed by the talented folks over at The Icon Factory

Once you own the code you can of course do whatever you want with it, it will be yours. I’m happy to provide on-going email support to answer any technical questions related to the code, but I won’t be available to do any actual development work.

I’m only interested in cash, not royalties, not stock, nor any other .com type incentives. If you are interested, send an email to leefalin@polarian.com and we can go over the details.

So what happens if I don’t end up selling? I’m not sure. One idea is that I could open source Screen Mimic and see where the community takes it, but I’d rather sell it to someone who is passionate about Mac development.

I’d like to thank…

Throughout this article as I refer to “we”, I mean my wife and I. My wife has been a wonderful strategic advisor, companion, and friend. Anytime I have suggested a bad idea my wife has talked me out if it, and anytime I have suggested a good idea she has encouraged it. There would be no Polarian without my wonderful wife.

Thankfully this isn’t the end for me in the developer community, my research project is such that I’ll still be doing active Cocoa development, just in the scientific/academic community rather than the small business one. Maybe one day when school is finished I’ll return to the exciting and rewarding world that is mac small business.

But for now I want to thank all of the other mac developers that have made this such a rewarding experience for me, I started to name all of you, but it is just too long of a list and I’m sure to leave someone out. I also need to thank all of our customers, all of you that have made Polarian a success.

Let me end by saying again that this has been a wonderful experience filled not just with time spent coding, but time spent interacting with lots of great people. Thank you again.