Category Archives: Infinity Softworks

Writings on running Infinity Softworks. Lessons learned from over a decade of history.

The Devil’s In The Details: Designing a Login Screen

Posted on by

I have been writing a lot of code lately for the new product I hope to share with you before the new year. The past two days I worked on a login/create account screen. Two days ago I wrote the shell, got the views created, did all the data entry and set up the basic structure of the controller. My designer set it up to be perfectly centered on the screen so I had to do little things like move it up when the keyboard appeared but only if the keyboard covered the form. Also, on the iPhone, once the keyboard comes up there is no button to make it go away. Touching outside the form hides the keyboard, thus uncovering the additional options. I hooked everything up and made sure it worked in the application the way I wanted. Then yesterday morning I handled all the error cases.

Error cases, for a log in screen? Yes. Login screens are funny little things. They look so simple yet if done right they are extremely complicated, from both a design and technical perspective.

Let’s start with technical. There are only two “good” outcomes in a log in screen. Option 1 is that the credentials entered matched an account and the user was logged in [1]. The second is that the credentials are a new account, an account was created and the user was logged in. But there are numerous “bad” outcomes, everything from the server being down to no Internet connection to bad passwords and email addresses, to incorrect passwords with matching emails [2]. In addition a good login screen must handle special cases like the user forgot his password or, for sites that make you verify an email address within a certain amount of time, verification failures [3].

And that leads me to the second thing: design. The app requires an account so the login view is the first thing the user sees. It not only needs to handle all these cases clearly and succinctly, helping the user when she runs into trouble, but I also needed to remember that this is the first experience she will have with our product. The login screen, albeit functional, also needs to represent the product once you get inside.

Our designer did a great job with the design. It is clean and simple. The interface is straight forward and offers features for those that aren’t certain they want to commit to an account yet but would prefer first to get a better perspective on the product. This is the era of app stores where people download apps, especially free ones, without even reading the description. We didn’t want to assume the user was familiar before installing.

I spent half the day yesterday getting all the error cases worked out, displaying each message with an alert and the alternatives for handling the case. For instance, a bad password (meaning an account was found but the password doesn’t match) could mean that it was just typed wrong or that the user forgot the password. We wanted to make sure both options were available.

The problem was, at about the five hour mark, I realized I hated the way it looked. The alert dialogs were unsightly popping over my form and slightly hard to read with the transparency. It was difficult, too, to relay the options in a straight-forward way. I also felt it needed an indicator so the user knew when it was working. I hate views that take a little time and give no clear indication that what I did had any effect.

So I went back to the drawing board. I stuck with the same login interface my designer designed, but instead of using alerts I created a second view that mimics the login view in appearance but first displays an activity indicator (spinner) before displaying a message, if there is one. The primary choice is highlighted cleanly, with secondary choice options below it. It took me seven additional hours to map all this out, set up a structure so all of this could be handled succinctly, and then make sure it all worked correctly.

I’ve designed a number of log in screens now and tried many different things with them. I never like the way they turn out. I know 95% of customers will spend five seconds on this screen, enter their credentials and move on, without realizing how much time and attention to little details went into it. I’m proud of the entire project and believe it will be a huge success. But when someone asks about the piece of code I am most proud when this project is completed, I may very well say it is this login screen.

—

[1] Technically not logged in. Instead the credentials are valid and they are stored in the app. Each time you access the site the credential, using SSL and other means of protecting your data, are passed to the server.

[2] The complete list of cases are: 1) an account is created and credentials stored; 2) the credentials are valid and stored; 3) user requested a new password; 4) no account exists with this email address; 5) the email is found but the password doesn’t match; 6) the server is down or there is no Internet connection; 7) the email verification was never completed and time has expired to use without verification; 8) invalid username (we handle this case but don’t use one as of this writing); 9) invalid email address; 10) invalid password; and 11) the account is suspended.

[3] Yes, I am using the word “user” (instead of “customer”) very deliberately.

Writing Apps From The Bottom Up

Posted on by

I’m having a great time writing code. I wrote most of the code in the early days of Infinity Softworks, from 1997 to 2000. In 2000 we added employees and had a development team so spent my time managing the company, focusing on business development and marketing. In 2007, though, when the company got small again, I started writing code again.

I wrote code first for the BlackBerry then for iOS. That first year or two writing code was a slog, just trying to figure out my way. powerOne still has much of this early code and, frankly, it’s quite ugly internally. The design of the app changed substantially from version 1 to version 2, and then was hacked again to support the iPad.

But now, with the new project, I get to start from scratch. It is hugely liberating. We ended up needing iOS 6 for the project so we don’t have to worry about legacy OS versions. We designed the product before we coded it so we aren’t making massive UI changes that we have to hack in. In fact, we wrote big chunks of code in side projects to test stuff out first. While doing this I also went back and studied a lot of sample projects that others wrote, read a lot of documentation and a couple of iOS programming books.

Once we started with the final project I had a much clearer idea of not only how it would look but also how I wanted the code to be structured internally. We started with the database models, saving records and settings. Then we wrote all the sync code and the server back-end stuff. Then we shifted to the front-end. Before I’d write one  module to completion then add in others. This time I said forget the final graphics and instead make all the screen animations function. And instead of starting on iPhone-sized screens, we instead started on iPad believing the shift to the smaller screen will be simpler. From there we got the basic app functioning, saving real records, and editing those records. Next comes more functional integration and then final graphics. This order feels more natural then the UI-down approach we took with powerOne.

I’ve still had too many meetings lately and my time to program has been limited. But it still feels like progress in being made and much quicker then in the past. I can’t wait to get the first rev into your hands.

powerOne Calculator for Android Beta Now Available

Posted on by

I’m excited to announce that we released today the first alpha version of powerOne calculator. You are welcome to download and try it here. The first release includes bundled templates and a full working algebraic and RPN calculator. We will be adding template creation, Library access and more soon.

Please keep in mind that this is pre-release software which means it is feature incomplete and buggy. If you’d like to assist us in finding bugs, we’d love your help!

In The Transition

Posted on by

Fred Wilson is running a Monday series on sustaining business. I think this is very important. Young entrepreneurs need to understand that you can indeed run a business for a long time and that can be a good thing. I think we over-glorify quick wins and fast growth in the tech community. Here is Fred’s first and second posts on the topic. In the second, Fred talks about the transition as market conditions change:

A company that I’ve worked with for more than a decade saw the industry it services go through some painful transitions in the 2008/2009 downturn. They built an entirely new line of products that service the growth part of the industry while working to maintain the older products through an orderly and gradual decline. It’s been a difficult transition because it has meant that the company’s top line hasn’t grown during this transition. But the company is still in business and the new products are growing quite nicely.

We are in a similar boat here at Infinity Softworks. We too are transitioning — or at least we hope we are — from powerOne calculator to a new product we hope to formally announce in the next few months. It’s not that powerOne will go away. We hope to maintain and improve it for years to come and are even working on an Android version as we speak. But we are hoping the new product will supply the revenue growth we desperately need and that powerOne has not provided. Here was my addition to Fred’s post:

I’ve run my software company I started in college for 16 years. It hasn’t been on purpose. It just so happens that I have a vision that has yet to be satisfied and I keep trying to achieve that vision.

The last few years have been brutal as the market (mobile computing) completely collapsed then re-birthed from the ashes. Our successes were built on partnerships and in the re-birth, first those relationships became harder because control of the industry moved to carriers and then the software side was completely (I don’t have the right word) gutted by [the App Store]. It’s not possible to sell [our] software the way we used to and at the sustainable prices we used to.

I’ve spent the past few years trying everything with the old products to make them sustainable again, everything from different business models to different partnership strategies to different product mixes. All we wanted to do was give us a baseline so we could focus on new ideas to achieve that vision. We have never been able to do that. But we have a unique new perspective and pursuing it fully. I said to myself that if this crashes and burns I’d rather do it making the transition then trying to revive the old, although the gravity of the old product is very strong and powerful.

Two lessons as we attempt this that Fred doesn’t mention here but are critical. 1) We may not be able to take the old customers with us. This is very hard because we owe these customers a lot and these customers LOVE our products, literally carried decade-old PalmPilots to use it. They are a huge pull. But the market has changed and the old product doesn’t work anymore from a revenue/business model perspective. Old customers are a glorious and horrible trap [1]. Learning from them without giving in to their wishes of a better old product is extremely hard.

2) The worst part of making the transition is the psychology. It is hard to explain. It is part grieving process as we deal with old successes dying. It is part fear as we have no idea what we are getting ourselves into. It is part sadness as we said goodbye to 90% of the team that got us success in the first place. It is part bull-headed-ness, obstinance and wanting to spit in the face of everyone who wrote us off. But most of all it is excitement for what the future holds about doing something different that might finally achieve the vision we set out all those years ago and have yet to achieve.

At this stage of the game, the lows are really low and the highs are really high, and the true believers are few and far between.

It’s not like we will abandon powerOne. It’s a great product that satisfies a need for many of my beloved customers. And I do believe there are a contingent of powerOne customers who will absolutely love the new stuff we are working on. I hope to make true believers of more of them soon.

—

[1] I mean this as a term of endearment, not in any negative way. Customers know what they know, and they know powerOne and want more of it. As an inventor I can’t rely on my customers to see the next thing until I present it to them, and even then they may not get it.

Hacking Away On The Bleeding Edge

Posted on by

We are doing some very interesting development work lately, although none of it is in releasable form yet. We decided with our most recent project that instead of just starting from the beginning and building one big project, we would build a series of small projects that did distinct tasks. This means we can easily test a single concept or idea long before we have to make sure it plays nice with other code.

Sometimes these projects are a one-day event. For instance, we will create a completely separate project just to make sure an animation works the way we want. In other cases the project is long-term. For the new app, we spent well over a year and a half just playing with the engine to make sure it reacts the way we want, for instance.

The latest component we are working on is something we have been playing with for a month or two now, off and on. In this case we started it as a separate project because the code uses concepts that are right on the bleeding edge of technology. This technology takes a web page and turns it into a rich text editor, a la Word or Pages.

As I mentioned, though, this stuff is bleeding edge and lots of things have not been thought through well in this world. For instance, it is painful to get the cursor position and figure out where it is relative to the screen. Why do I care? Because when typing into this kind of view I want the cursor to be on screen and for some reason no one thought to do that automatically. After spending an entire day playing around with the code and pulling out what is left of my hair, after spending a week researching the topic, I finally came up with an elegant hack that will do the job perfectly.

When this is all said and done, we should be able to take all these sample projects, move them into the primary one, clean a few things up and be ready to go.

That’s the theory anyway.