how far do you go in your process while using Framer? it doesn't make sense to code the entire app right? just the important interactions to be used in the production code
I think everyone will have slightly different opinions on this.In our company, Framer has multiple roles, depending on the task:
1. simple interactions : if I click this what / how it happens? Here we're doing pretty much motion design prototype. Framer can be replaced here by After or most usually in our case, by Quartz Composer or Principal now.
2. One, core / user driven flow protype: so this resembles a full app but it's pretty much a "scripted" path, like you would see in invision, but with the advantage of getting as "detailed" as time permit. These we use either for internal validation or for small / quick usability test
3. Full apps : We use this closer to the end, as both usability test artifact or even more commonly, as a guideline for the project if the implementation team needs one. Here the prototype does get closer to a full app, but still not core pieces maybe missing.
In the end: NONE of the work is used in production (as code) but it serves as guideline / documentation or test.
One perspective, but it will resonate with others for sure :)
very useful information, Yeah i mean of course you can't use any of this in production code. and what of these 3 approaches of is the most common for you guys?
To be honest, we use 1 + 2 in All projects, with 3 being used in all projects where we're not doing the final build ( handoff ) and rarely in internal projects.
Oh all right, interesting. Thank You.
It depends. Small pieces tend to come together to build a full app proof of concept which also can be used for testing. But also there are many features that also don't function but the core part / unique part that you are trying to design/define specifically.
this is a bit off-topic but I figured some of you may have an interesting opinion: what would u prefer for a native cross platform app with one code base: Meteor or Angular 2?
Small product studio experience:
Most of the stuff we work on is for the web and we prototype in the browser so we can reuse as much code as possible in the final product. We almost never use full prototypes.
With native apps, it's much different. We build numerous tiny prototypes and longer flows to do user testing. The main difference is that in the second case, unlike the first, we are nor familiar with the final product's development environment. I'm currently learning Swift to make hand-off smoother, but prototypes are the essential way we communicate precise ideas with developers.