A little while ago, I was thinking and I realized one of my apps, Dismissrr, was due for an update. I quickly decided to make it from scratch and thought of a fairly good idea for the UI. I dove right in and started making models and classes for the app. This was my first mistake, I should have sat down, wrote a features list, made some UI mockups, and strategized how to make it. In all fairness, the app turned out pretty well; however, it took longer than I would have liked to make. This was due to the amount of time I spent overdoing things and stupid ideas I didn’t think through. In this article I will talk about what I over did in the app and what ideas I had that shouldn’t have ever gotten past the drawing board.
Complicated Algorithms for minor issues
The image to the left is a screenshot of the app. One of the things I spent the most time on was the label in the scanner circle that says, “Smith.” If you are a developer, you are most likely wondering how in the world I could make a UILabel that complicated. While I was coding it, I realized that if the user is over a black background, the label is hard to see. I proceeded to write an algorithm that changed the color of the label to the opposite of the color it was over. This led to a whole number of memory issues and other problems coming up. After I was finally done, the color changing didn’t even seem natural and was confusing. If I had just thought about the time it would take to do this vs the payoff, I would have realized it made no sense to do. Yes, I could have spent a few more hours getting it to work well; however, it wasn’t worth much so I just scraped it.
Not figuring out transitions
If you look at the bottom of the screen, you can see it says “Slide left to dismiss students.” As you can imagine, this label wasn’t part of the original design in my head. After making the whole app, I realized I was missing a whole major feature of the app. From the beginning, I figured you would tap or swipe somewhere to open up that screen; however, I didn’t think where or how the user would know and just forgot about it. Eventually, I added it into a UIScrollView. After I added it, I thought about how logical it would be to swipe. I concluded it would be logical to swipe to see it. Luckily, after I did this I made a good decision: I asked 3 people how they would try to get to the “dismiss” screen. It took them quite a while to figure it out. I knew I needed to change something hence the label at the bottom. While it works very efficiently, it looks awful in my opinion. If I had just taken the time before making the app to think through the UX and UI there would most likely be a far better solution.
Creating unneeded Restrictions
If you look at the screenshot, you will notice that there is a circle in the middle. The purpose of this circle is to show the user where to position the QR code in the frame. When I was first writing the code, I tried to restrict where the code could be so it wouldn’t scan if it wasn’t inside the circle. One of the worst ideas I have ever had. Let’s take a step back and make a pros vs. cons list.
|No comment||Makes the user frustrated because the code won’t scan|
|Creates complexity in the code|
|Makes it unclear how the app is supposed to be used if the codes will not scan|
as you can see, it’s a pretty one way pros vs cons list. Obviously it was a bad idea.
I didn’t make a spec
This isn’t quite as major; however, it was a mistake. Before I make an app I have a protocol that I like to follow. I also tend to do it when I am working for clients. I will make a document and call in the vX.x spec. This document will list all the features and details on what each one should do. When development starts, I essentially lock this document and it cannot be changed anymore. I develop what is written and don’t change anything. Of course, I always end up making small changes; however, nothing major gets changed. This is nice because it forces you and/or your client to think about exactly what features are needed and second, it keeps you on the right track in terms of feature development.
There were a few things I wanted you to get from this article (besides for that my app had a few UX issues when in the development stage). The first being never neglect the planning stage (unless you are at a hackathon in which case you should shorten it). It is just as important if not more important than the coding stage (I know it may be hard for some developers out there to believe that) :). It will save you many headaches down the road. Along with that, try to make a spec with a list of features for the release. This will prevent you from going crazy adding unnecessary features. The second thing I wanted you to take from this article is think about if what you are doing is actually important to the app or if it would just create confusion. Part of this whole minimalism thing is removing unnecessary features. The simplest things are the most complicated; however, you should make everything essential to the app perfect before you go on to add smaller features (such as color changing effects). Lastly, I wanted you to learn all the boring color animation things you learned to do when you were starting iOS development actually may be useful one day. For more tips and to ask me questions, follow me on Twitter.