loading...

Mobile first, but if desktop, additional UI

patarapolw profile image Pacharapol Withayasakpunt ・1 min read

How would you approach this problem? When the screen size is larger, there should possibly be more UI. (And when screen size is small, there shouldn't be necessary bundle size.)

It MUST never fail on mobile.

Also, if required, when installed as mobile native, there can also be additional features.

  • Latest web API is probably enough for most things, anyway

Discussion

pic
Editor guide
 

Web Push Notifications

That's another thing that keeps me on Electron. You can integrate its native desktop notifications with the web push API (I'm pretty sure Slack is an example of that. If not, multi-messenger apps like Franz, Ferdi, and Rambox are).

How would you approach this problem? When the screen size is larger, there should possibly be more UI. (And when screen size is small, there shouldn't be necessary bundle size.)

You should consider a responsive strategy in desktop apps similar to web, and the same applies to mobile apps as well, just handled differently (different screen sizes, portrait vs. landscape with rotation, phone vs. tablet...). If you decide to use React Native/RN Web/Electron (with or without Expo) like I do, you need to consider a solution that works with React Native's StyleSheet API (a subset of CSS, based largely on Flexbox) and/or rerendering when dimensions or orientation change (RN's Dimensions API can be frustrating if you try to lean on that). The libraries react-native-extended-stylesheet and react-responsive are good places to start.

It's also important to note that one of the key principles of responsive design that many people seem to forget is: "Don't punish the user for their choice of screen." In the current landscape, that principle should be extended as much as possible to the user's choice of PWA vs. dedicated mobile app vs. dedicated desktop app. It takes some ingenuity to make it work sometimes, but the user of one screen factor or platform shouldn't suffer reduced functionality compared to others.

For example, I can do things in the Trello web app (even in a mobile browser) that I can't do in the mobile app (and their official Mac app -the only desktop OS where they have an official app IIRC - has never been a priority, as the App Store reviews make quite clear).

 

While I understand your point of responsive design, I feel we shouldn't be constrained by mobile first, and have to design for iPad (Portrait and Landscape) and desktop (usually Landscape only) as well

 

Mobile first shouldn't be viewed as a constraint. It's merely a starting point. You mentioned yourself bundle size and "It must never fail on mobile." An easy way to recognize how it helps is to compare to a similar (though not completely overlapping) approach:

Mobile-first -> progressive enhancement
Desktop-first -> graceful degradation

While you may need elements of all paradigms on both sides of the comparison, mobile-first and progressive enhancement are easier to implement because you're adding what you need as you go rather than subtracting (which often ends up being more like replacing than actual subtraction).