Hacker News new | past | comments | ask | show | jobs | submit login

Also UIs which don't have to support an actual data manipulation tend to underestimate dealing with the edge cases of that manipulation - which I tend to think is why you never get too far from the shell in Unix-likes.



And why so many database-backed webapps look like a frontend over a database, and virtually all mobile messaging apps are frontends over TCP/IP, and web directories before Google were just webpages with a whole lot of links.

It turns out it can be pretty profitable to break with the machine model of the underlying data and instead present things the way your users want to see them, even if it makes the code necessary look complicated and gross. The danger with building the data model or API first is that you'll build the easy, obvious API, which is the same easy, obvious data model & API that all your competitors build. Start with the user instead and you can end up with some really powerful differentiators, at the cost of it being a bitch to transform into working, sane computer code.


It turns out it can be pretty profitable to break with the machine model of the underlying data and instead present things the way your users want to see them, even if it makes the code necessary look complicated and gross.

It certainly can, though I think you’re still figuring out a data model first on those projects. It’s just that you’re starting with how the information is organised and manipulated from the user’s point of view, then figuring out an internal representation to support it afterwards, rather than the other way around.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: