Right, so I spent several hours yesterday trying to figure out why I couldn’t adjust the height on my HTML form select elements. I was utterly bamboozled after stripping out all inherited CSS and playing around with the web inspector. The problem?
You can’t adjust the height of a select element if it has no border.
There’s probably a very good reason for this but my gripe is that it’s not visibly apparent that the select dropdown is borderless in the first place.
Anyway, hopefully this will save someone a little time further down the road.
After launching a product, you’ll likely be inundated with feature (and support) requests. There will be features that tons of people ask for, others not so much.
The big reactions come when you make an update to your product, though. I get contacted on a daily basis by people who say my latest game is too hard. Others say it’s too easy. Some say it has a good UI, others say its really unintuitive.
It’s super important to have an anchor when faced when all this feedback is trying to pull you in different directions. An anchor in this case is an ideal that gives the good ship Startup the ability to take on the storm of this (sometimes vitrolic!) feedback.
The anchoring ideals for my app, Hipster CEO, are (in priority):
- Does this change improve the player’s understanding of how a real startup works?
- Does this change improve the overall app experience?
Like most things in life, these two questions are subjective so some expertise needs to be applied.
I’d encourage you, before you even begin building an app, to consider your anchors. Some good ones:
- Does this change add value that people would pay more money for?
- Will this feature be used by 80% or more of our customers?
- Does this change come at the expense of another key feature?
- Does this affect our main goal or key message?
When your business has a core belief then decision making gets a whole lot easier.
My buddy Ed (@ClearPreso) recently wondered on Twitter what the real draw was on Snapchat and believes it just a flash in a pan technology. I wouldn’t blame him for making this assertion but I think he (like most people) doesn’t see it’s true value.
Some “experts” believe it lies in the push and hold requirement: “If your thumb is pressed against the screen, it’s very likely that you’re staring at what’s in front of you.”. Well, duh. But guess what? Sites like Forbes and JOE.ie put an ad right in front of me at the start too and I just skip it.
If Snapchat users don’t want to see ads then they won’t open them.
I’d probably open the messages I’d get from the likes of Heineken – companies that produce great ads, basically, who have solved the attention-grabbing dilemma by being creative (who’d have thought that would work!?).
A common piece of feedback regards my latest app is that it’s too expensive. It costs €2.69 ($2.99); considering the usage customers are getting from it, I (and, more importantly, they) consider it very good value for money.
It’s the first time I’ve really ever had to face the software pricing dilemma and it made me wonder:
“Why is there such a gulf between what an app developer & a consumer thinks their software is worth?”
When it comes to mobile apps, a common pricing comparison is the cup of coffee which generally costs about two bucks. Take the top 20 paid apps in the App Store right now and the average price is €2.10. This makes sense as the average consumer is willing to pay about 99c/€1.99 for an app.
However, once you go above the two quid price range, things get a little more complicated. It seems as though an app priced at €2.59 can no longer be considered an impulse purchase. A developer that decides to charge more than three bucks for their work can often be met with a ferocious anger that is usually more at home at a right-wing BNP rally.
Going back to our cup of coffee comparison, you’re probably happy paying two quid for a quick take-away. Chances are, though, that you won’t mind paying 40-50% extra for something more up-market and it’s here where our comparison breaks down. With mobile apps, we have a consumer expectation chart that looks a little like this:
Perhaps the problem is consistency. You generally know what you’re getting when you pick up your morning mug o’ joe. Apps are different. Their price often doesn’t reflect their true quality. Great apps sell for 99c; pure muck sells for €3.69.
About a year ago I started working on a new Rails project. I’d previously done all Rails jobs with ActiveRecord but decided to give DataMapper a try this time as I heard it scaled particularly well and was classed as a “more complete ORM”.
It’s been a challenging experience at times and I thought I’d share some of the gotchas I came across in the past 12 months.
Lack of documentation
The fact that I have to write this article at all is testament to this. The documentation on the DataMapper website is okay-ish but it feels more like an introduction and certainly not the place for in-depth reference.
The community is also considerably smaller than ActiveRecords which means if you’re really stumped then there’s less helping hands available, especially for those really awkward bugs – which brings me nicely onto:
Many to many relationships issues
The documentation on associations specifies that you may use the :through => Resource syntax to create n-to-n associations between models. This means that if you have a model User and a model Activity then DataMapper will create a activity_user link table for you automatically. It also creates a link model which is loaded when Rails fires up.
Thus when you go to add a link between the data model (eg. adding an activity to a user), you’re really actually interacting with an ActivityUser model – DataMapper is just doing the heavy lifting for you.
This is all well and good unless you have configured cache_classes to false in your environment.rb file (which most people will in development, its one of the big benefits of using Rails and similar frameworks). In this case, the join model doesn’t get reloaded and when you go to update the relationship between two objects DataMapper will try to create a relationship where it should not.
The issue is spoken about in more detail here but the best way to mitigate this issue is to avoid using :through => Resource and define your join tables explicitly.
Validation works fine in DataMapper until you try to persisting an object with new relationships at the same time. Let’s say I have a User object with contains a Location; so on creation of the user, I create my new Location and set it on the new User object.
If the location fails validation when I try to persist the user then the save will fail but the errors array on the user will be empty. This becomes quite frustrating when working with a model with multiple relationships and you have to check validation on each of them individually.