I came across a blog post criticizing aspects of Scala: http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html I’ve thought about it a bit and I’d like to share my take on the criticisms.
First off, the criticism of SBT doesn’t hold a lot of water for me personally. SBT isn’t the simplest build tool out there, but it gets the job done in my experience. Build toolchains are a convenient place to hook on a lot of responsibilities but I don’t think that’s a good idea in general.
As far as training goes, if you believe you’re using the right tools, then it’s worth it to take the time to help good people get up to speed on those tools. I’m okay with funky code in the system because funky code is a part of the learning process and I think there’s always learning to be done in software.
Regarding complexity, I expect there’s a trade off between expressiveness and complexity. I think the less code you have to write to express your thoughts, the more maintainable it is in general (not a concept to be taken to extremes). The question is whether the complexity is worth the effort to learn/master it.
Writing highly performant code is an art in any language and there are always caveats that go along with it. Focusing on those aspects every time you write code is a premature optimization. I suspect there’s lots of ‘ugliness’ in the performance sensitive parts of most systems.
Should everybody be using Scala? Absolutely not. The points are valid and may be enough to turn off some from using Scala but I think the trade offs are worth it.
iPad apps that support direct manipulation of objects in the interface can be a joy to use, but figuring out how to use them can be a pain. A lot of apps provide some sort of initial experience or help system with their apps to assist users with getting acquainted with it. For a great write up of design patterns related to this, check out design patterns for iPhone apps I had to answer these questions for my own app and learned a few things along the way.
It takes a lot of time
If you’ve used the app before or involved in creating the app, then you’re inherently disqualified from determining if the initial experience is good. You can test it and make it better, but you don’t know if it’s good until you test it again. It took me several weeks of testing and refining the initial experience before I had a version that tested well, most of the time was spent finding people to test the app.
Everyone’s an expert
Unless they’ve never used an iPad before, people will come to your app with preconceived notions of gestures that your app should support. They prefer experimenting with the app rather than looking at whatever you provide. I think this is a good thing and my app attempts to encourage discovery while providing enough assistance so users don’t get lost.
There’s more value in things unsaid
It’s a good idea to ask people what they’re thinking as they test your app. The bad part is most people are not used to thinking out loud and giving good feedback on apps. Watching people’s expressions and body language is a far better indicator of their experience than what they say. For me, there’s no replacement for doing face to face testing.
After many weeks of testing, changing and refining I went with screen overlays for the initial experience. I found that they provide a good level of assistance without being intrusive. For anyone that’s curious, here’s what an overlay from my app looks like:
It’s more open in the ways that matter to most people.
Is anyone surprised by this? Will other service provides make the same decision or pay the tax to play on iOS?
Great writeup of different ways to introduce functionality within apps. The examples are just as applicable to iPad apps as iPhone apps.
I get into discussions with developers on a regular basis about the merits of native mobile apps vs mobile web apps. I’m not advocating that native mobile apps are the right choice every time. There are many reasons to build a mobile web app, but UX isn’t one of them.
It’s Bizarro World!
Using HTML5 and CSS3, it’s possible to create mobile web apps that almost look and behave like native apps. The problem is almost doesn’t cut it. There are a lot of nuances to the interactions on mobile devices. For example, check out the animations involved when you tap in the Search field and start typing in the Contacts app on the iPhone. You could probably approximate a similar experience in a web app, but it’s not going to be the same. It’s going to be a “Bizarro” version of it that some people will notice and leave others with a nagging feeling that something is not right about it.
The growing chasm
Mobile is an extremely competitive industry with new capabilities being added on a regular basis. For example, iOS 4 gave developers access to multitasking, printing, calendar, photo library, video capture, etc. Would the user experience be improved by utilizing some of these features? How many of those capabilities are available to web apps? The next version of iOS will bring additional capabilities that also won’t be available to web apps.
Bringing a knife to a gunfight
We all have competition. You can choose to compete on features, availability, user experience, etc. The greatest benefit of a mobile web app is that it’s available to a large number of platforms including the “Next Hot Thing” whenever that comes out. However, people care about other platforms as much as they care that a web site is standards compliant. People care about the experience they get on their platform. You may choose not to compete on UX, but your native mobile app competitors most certainly will.
What’s the significance of UX to your app?
What if meetings were collaborative? What if things got done during your meetings?
The goal of Lean UX is to answer how to fit design into the product development process along with Customer Development and Lean Startup practices. Here are my top 3 takeaways after participating in the 2 days of awesome known as the Lean User Experience Intensive (LUXi).
Do UX like the pro’s
There’s a world of difference between reading about UX techniques (sketching, personas, scenarios, etc.) and doing it. The workshop provided the guidance and opportunity to learn some of these techniques. The value of learning and applying these techniques with UX pro’s cannot be underestimated. Whether you’re flying solo or part of a larger team, your product will be better with these techniques at your disposal.
Divide and conquer
Sometimes design can seem like an intractable mountain when you’re trying to accommodate all the wonderful ways you imagined your product can be used. Get the ideas out of your head and externalize it into useful and actionable items. Intractable problems become a lot more tractable when you can divide them into smaller ones.
Make it Lean
Lean systems are about reducing waste, which is defined as any effort that does not contribute to the product efficiently. All design incorporates a set of hypotheses that we believe to be true. Invalid hypotheses is wasteful as it leads to redesign or failure in the market. Lean UX encourages you to identify your hypothesis and opportunities to validate them with a handy mantra: Think. Make. Check.
The workshop has opened my eyes to new ways to incorporate design into product development. If you care about creating great products, then you should keep an eye on Lean UX. Big thanks to Janice Fraser (@clevergirl) and Tim McCoy (@seriouslynow) for hosting the workshop.
Refreshingly not as scary as their Android commercials.
“if you want to do custom roms, then buy elsewhere, we’ll continue with our strategy that is working thanks.” - So much for the root and load your own ROM option.
