6 ms·

While I think Jon made it seem a little easier than in reality, as someone who uses and designs for both mobile/desktop I have to agree that when done right it'

While I think Jon made it seem a little easier than in reality, as someone who uses and designs for both mobile/desktop I have to agree that when done right it's not that much more of a time investment - generally ~10% extra on a full design/build project. There's a real argument that in a hackathon 10% extra time isn't worth it, but in the real world where you don't always have 48 hour time limits I've always been in the opinion that the initial time investment is far outweighed by the benefits and the additional cost that you would incur by making it mobile-ready later (which usually requires either rebuilding the frontend templates from scratch or hacking away at the existing codebase in a way that is far less organized/sustainable). As far as the long standing argument of whether building mobile-first or desktop-first, I honestly think that's up to developer preference so long as the whole team is building with the same mindset. Building responsive, mobile-ready sites/applications isn't free, but a lot of web developers/startups seem to make it out to be much more difficult than it actually is when done consistently and right.

jonathanstark 12y ago
@robertnealan Well said. Having personally worked on responsive redesigns for ew.com, techcrunch.com, and timeinc.com, I know as well as anyone that designing a full scale responsive site can be hard. Really hard. That said, the hard parts are not the technology or the implementation. Rather, the hard parts are organizational dysfunction, legacy CMS software, integration with non-responsive 3rd party services like ad networks, and so on. The complete lack of those sorts of challenges in something like a hackathon means that devs are free to design in a way that maybe they can't do at work or for clients. My shock was that given such freedom, they choose to basically ignore mobile.
Daiz 12y ago
>There's a real argument that in a hackathon 10% extra time isn't worth it, but in the real world where you don't always have 48 hour time limits I've always been in the opinion that the initial time investment is far outweighed by the benefits and the additional cost that you would incur by making it mobile-ready later (which usually requires either rebuilding the frontend templates from scratch or hacking away at the existing codebase in a way that is far less organized/sustainable). Oh, I completely agree with this. I'd say that even during hackathons, mobile is definitely something you should keep in mind when you're building your design, markup, etc. just like you normally would so that things will be easier in the long run. However, the key thing is that when you hit something that would be easy to deal with on desktop but hard on mobile, you should just go the easy desktop route and leave the mobile solution for later (post-hackathon). And when you're building web apps, those kinds of moments will pretty much inevitably come because mobile is hard - compared to desktop, you will generally speaking always have less screen real estate (and input elements need to be larger, making it even smaller), a lot less processing power, lack of precise pointer input and hover (touch vs mouse), etc etc. Again, the point here is the difference between building websites and web apps. With websites, your biggest concerns are generally that the site scales nicely to various screen sizes and that links are comfortably clickable (and that it all looks nice). This wouldn't be all that hard to do even under time constraints. Web apps on the other hand generally feature a lot more (single-page) interactivity, and getting that right is a lot harder.

jonathanstark 12y ago

@robertnealan Well said. Having personally worked on responsive redesigns for ew.com, techcrunch.com, and timeinc.com, I know as well as anyone that designing a full scale responsive site can be hard. Really hard. That said, the hard parts are not the technology or the implementation. Rather, the hard parts are organizational dysfunction, legacy CMS software, integration with non-responsive 3rd party services like ad networks, and so on. The complete lack of those sorts of challenges in something like a hackathon means that devs are free to design in a way that maybe they can't do at work or for clients. My shock was that given such freedom, they choose to basically ignore mobile.

Daiz 12y ago

>There's a real argument that in a hackathon 10% extra time isn't worth it, but in the real world where you don't always have 48 hour time limits I've always been in the opinion that the initial time investment is far outweighed by the benefits and the additional cost that you would incur by making it mobile-ready later (which usually requires either rebuilding the frontend templates from scratch or hacking away at the existing codebase in a way that is far less organized/sustainable). Oh, I completely agree with this. I'd say that even during hackathons, mobile is definitely something you should keep in mind when you're building your design, markup, etc. just like you normally would so that things will be easier in the long run. However, the key thing is that when you hit something that would be easy to deal with on desktop but hard on mobile, you should just go the easy desktop route and leave the mobile solution for later (post-hackathon). And when you're building web apps, those kinds of moments will pretty much inevitably come because mobile is hard - compared to desktop, you will generally speaking always have less screen real estate (and input elements need to be larger, making it even smaller), a lot less processing power, lack of precise pointer input and hover (touch vs mouse), etc etc. Again, the point here is the difference between building websites and web apps. With websites, your biggest concerns are generally that the site scales nicely to various screen sizes and that links are comfortably clickable (and that it all looks nice). This wouldn't be all that hard to do even under time constraints. Web apps on the other hand generally feature a lot more (single-page) interactivity, and getting that right is a lot harder.