Mobile MVPs done by lone developers on a contract basis should be about getting something palatable and pleasant that works, not drop shadows and exacting transparency effects. Save that for a second version or when you have enough of a budget to get a designer that knows her way around interface builder. Getting too caught up in making a MVP pixel perfect is a cause of failure for both client and developer.
Mobile MVPs done by lone developers on a contract basis should be about getting something palatable and pleasant that works
Truth be told, something palatable and pleasant that works can be a very, very high bar from a UX perspective. When software collides with the real world, you get a lot of complexity. Even organizations the size of Google and Apple can't produce a Maps app that doesn't do wacky stuff that seems designed to frustrate the user while trying to get someone killed. By comparison, how something looks is dirt cheap. (As usual, it's far cheaper to signal quality than it is to build it.)
When it has to deal with the "real world," mobile QA and UX is hard, and doing it to a high level is probably greatly underestimated in cost while being quite expensive. They say a picture is a thousand words, and seeing it yourself is a few more orders of magnitude. If your only feedback is logging/callbacks/snippets of text from users, you're only getting a small sliver of the true picture.
For Android implementations, if you pay attention to the Material Design guidelines, even if you don't have a good designer on the team, it probably won't suck. It might be pedestrian and form-oriented, with less direct manipulation than it should. But it won't look awful.
This. For design-challenged people like me those guidelines are lifesavers. Ironically, I'm not a big fan of Material personally but it helps a lot to have these kind of guidelines handed down to me.
Your maps example is a straw man - everyone knows Maps is incredibly complex - not a small MVP. And your point about how hard it is to get things right further exemplifies my point which is not to get too caught up in pixel perfect details. There's no time/money/energy for that.
If your bar is too high on the UX side, as a lone contract programmer who is NOT the designer, you probably will have the same problems shipping as the person described in the article. Real artists ship. Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
Your maps example is a straw man - everyone knows Maps is incredibly complex - not a small MVP.
Not at all a straw man. Maps might be much, much larger than a small MVP, but Google and Apple have a lot more resources than a lone contract developer. You are the one getting caught up with scale. I'm talking about the increased complexity of apps when they have to bump up against the real world. I've been greatly offended and materially affected by seemingly arbitrary choices made by a developer on a username field. Namely, that starting to edit the username field would blank out the password field, instead of doing this on start-edit of the password field. In a time critical situation on low-bandwidth, this can leave a user with a password vault cursing, high and dry, while the app starts this kafkaesque cycle of doing the most annoying thing.
Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
If the aim is to make a substantive tool that stands up to real-world complexity in UX, someone, somewhere is going to have to spend a lot of time testing the heck out of it and make careful observations. Otherwise, the lone consultant is just going to check off the requirements, call it a day, and bill. The only alternative is to be really good about feedback, and implement in such a way that corrections can be distributed in a matter of a few hours or less.
Citation, please. I deal with clients on a regular basis who think that software with 20+ years of time invested can be duplicated by 1-2 engineers working for 3-6 months.
Earlier today, I had to give a rough estimate on writing a custom app that can read, write, share and sync arbitrary CAD files, and explain why building all of that might not be the best approach.
This was my thought too. A lot of the times I suggest doing a hybrid app for the MVP. It is an easier and more affordable way of getting a functional and decent looking app to market. Allows the client to test and fine tune more easily. Oftentimes after launch they stick with the hybrid app because it gives them enough of what they need. Other times they decide to proceed to native but now have a much better idea on what they really need/want and saved tons of money in the process.
I tried to put together a workable MVP as quickly as possible. The designs that I thought were aspirational designs for a finished product that would be completed eventually, but no, the CEO really wanted all of the fancy transparency, the exact button spacing, the exact imagery and fonts (despite the fact that they used fonts that weren't licensed for app usage...sigh...).
So we spent tons of time that was supposed to be MVP instead making a polished final product.
And then the CEO threw a new set of art to us and asked for a third redesign (ours was apparently the second, after the initial developer resisted making major design changes). And then a FOURTH redesign.
It amazes me that this guy (continues!) to get funding. But he's managed it. :|
I always felt that Interface Builder is _for_ designers who want to visualize and use something (only somewhat) closer to photoshop. A developer might more likely come at it from the other direction, not even touching IB and doing it all in code, then maybe adding modular IB elements when the layouts start to make the code unmanageable.
If you're not using interface builder as a developer, you're wasting a huge amount of time. Doing advanced screens (mostly) through code makes sense, but often it's a lot faster to use IB for putting together / building the more basic parts of an app.
I totally agree. I wanted to expand a little on basic vs advanced screens, and suitability for IB.
At work we had two teams who had very different opinions of IB's usefulness. In our case, it was based on the nature of each application. IB does not provide much value when the majority of the screen is dynamically determined: different elements based on user preferences, locale, document contents, etc. The team that disliked IB, their app was almost all dynamic (and lists/tables, whose cells were also fairly dynamic).
Our team, on the other hand, had a very static UI. It had very little runtime customization (other than the contents of labels, images, etc). We loved IB.
And then child ViewControllers came along, and made it easier to mix static/dynamic content on the same screen.
I haven't used UIStackView yet, but I suspect it also will help with screens that contain dynamic content.
This is a good point. I've been dealing almost exclusively with highly dynamic UIs, and that's almost certainly skewed my perception of IB's usefulness.
We built our designs on a modular approach where each element is contained in a tableview cell, so that part is done by code. The cells themselves make use of Auto Layout though.
While I absolutely hated AL at first (and the IB just plain sucks) I do find it very time-saving once it clicked.
For small to medium changes, by reading the XML. Everything is named sanely, and the XML hierarchy matches the view hierarchy. Constraints can be a little hard to understand, because they use opaque identifiers, but it's possible. I'll occasionally have to open the storyboard/NIB in Interface Builder to confirm/disprove something.
For large changes, it can be unmanageable. But large changes are hard to code review anyway, so we try to avoid those.
Interesting. I've worked with a few designers who had Xcode _installed_, but they were mostly using it for the Simulator. Using IB wasn't something they were comfortable with. I'd be really impressed with somebody who's a Sketch/Photoshop wiz coming over to IB and being productive.
On the flip side why would a non-developer bother to install Xcode and learn IB when they can export their ideas directly from Sketch/Photoshop into clickable "prototypes"?
Back when IB was a separate tool, I'd agree with you. I'm not going to look for old docs, but I'm pretty sure I ran across something from six or seven years ago that mostly said, "IB can be used by non-programmers to make a UI, and then dev can create the code to hook to the IBActions.", or something like that.
Whether it was written down or not, it seems like a good idea in theory. The old, stand-alone IB wasn't all that hard to figure out (though struts and springs might bring the death of your sanity). Get the UI all prettied up, and hook up an implementation behind it. Not that I've ever seen that in practice, however.
