Putting your wireframes in a prototyping tool allows you to quickly test and figure out if the interactions that will drive your flow are good or not. You really don't want to know this only when you're done choosing your fonts/colors and aligning everything.
With the "wireframe prototype" you get a good idea of the structure and the main interactions. The mockups can give you the look of the app. The final high quality prototype is also not always super useful, and should be used, imho, as a communication tool with the clients if they need it.
Demo is where you combine look and feel with core functionality. It can still be very hacky under the hood and use pre-rendered output etc.
Granted, this assume complex functionality. If your reusing a common pattern like website with checkout then it's a non issue.
sketch -> wireframe -> prototype -> stylish paint job
Some categories exist in such abundance that one way to stand out is the create superior interaction.
But it's not always necessary to be successful.
Therefore, instead of trying to parse his description of "wireframe", it may be better to just look at Balsamiq's capabilities: https://balsamiq.com/
To me, it looks like his idea of wireframe is something "clickable" ... such that it launches another fake page, but not functional. A Balsamiq/wireframe tool is something non-programmers like designers and business leads could use to communicate a UX/UI.
Mateusz Warcholinski wrote: "My favourite tool to do it: Balsamiq"
After studying Balsamiq, work backwards from that to get an idea of what he meant by "wireframe" and whether or not it has "functionality".
I would agree they aren't tightly coupled but there is definitely an association there that can't be completely separated.
If someone says "I need a wireframe/mockup/prototype" then clarify exactly what they are looking for - functionality? layout? content?
With regards to "when should one introduce interactions / logic / UI" decisions, I think it depends on the sort of application you're building, who is the user, and what are the risk factors that need addressing.
If the goal is to build a simple blog-like site for a mom-and-pop shop, then you might want to start with paint & chrome, because while many platforms could suffice, the importance of front-end gloss might drive implementation choices.
If the goal is to build a geodetic-measurement app for plate-tectonic specialists, perhaps you want to start with the engine, without which the entire effort is pointless.
To me it's all about
- Achieving a shared vision early then refining
- Surfacing risk areas early then addressing
Past that, how many iterations you need and what you call them is mostly semantic, once you understand what you're trying to achieve.
I wrote this, because I couldn't find anything good enough describing this topic. We often got aks by our our customers or first-time-founders - What is the difference? And why and how they can do it?
That's not to say it's a great article. But I can see why some people might find it intellectually interesting or useful because it cleared up confusion.
Hacker News is not uniquely immune to Endless September . The expectation regarding dealing with it, using civility, is not unique either. But it is uncommon.
those terms are arbitrary to some extend. You can have any degree of interactivity with any of those states.