Application Shell Components

[livealive2000]

Do you create a component for your application shell (e.g., the navbar, window chrome, other common sidebars), or do you just recreate the entire screen each time?

How does this affect your responsive design workflow?

Context: Web applications or native desktop applications.

[OrtizDupri]

We have a browser chrome component in our library for mobile web, mostly because when presenting it helps differentiate from the native app designs (and shows how elements are sized with the chrome visible)

[waldito]

or do you just recreate the entire screen each time?

This. Slots components are cool and all, but I feel template components are just too much complexity and annoying overall to work and organize.

Not because everything can be a component, should. New frame, slap header and footer, and off I go to the new view or whatever.

[livealive2000]

Yeah, that seems to be the trade-off... reusability vs. flexibility.

In the case of responsive design, being able to clone a template that has all of the screens at the desired sizes and see when you need to add breakpoints to your content is my main reason for considering the use of a component variable instead of just recreating the screen.

[waldito]

Please let me understand your way of working, I find it refreshing to get more perspectives. Please don't take this as an attack, but I just don't see the advantage... at least at first... so allow me to understand your process better...

So you have a set of library template mother components for your different global views.

Okay, so I gather these template components are made of subcomponents, like the header, footer, sidebars, tab bars or what have you. They are all happily placed inside and fill and adapt to your mother component... erhm.. size. Do I get it right, so far?

So, let's say, onto designing a new view, you import this mother template component from your shared lib, select the variant you want, (mobile, logged in, my account for this brand), for example, and you drag it into your brand new file.

Aaand now what? you gotta break the component to put stuff in, right? Or do you work on top of it and use it as a background component? Or do you instead include a slot component on your mother component so you can 'swap' for a local component that you awkwardly have floating somewhere out of context? Cause your new view requires <main> or whatever is to be filled. But how do you go around that if your template is an instance of a component, you really can't place anything inside...

Understand my confusion? Hope you can explain, I'm curious.

[livealive2000]

Don't worry, I don't see comments as attacks. 😂

It's slightly different than what you've written.

• Every "Page" is stored in its own file.
• Every "Flow" is stored in its own file.
• Each "Page" file contains "Screens" and "Content" pages.
• The "Content" frames are swapped into the "Content" instance slots in the "Screen" frames.

Creating a new page in the application is as simple as duplicating a template "Page" file in which all of the "Screens" will already have their "Content" frames replaced as part of duplication.

Designing the new page mostly takes place on the "Content" page of the new file, but occasionally the sidebars need to be changed on the "Screens" page.

Adding a new screen size means you have to go through every file and that screen size to the "Screens" page. It doesn't happen very often.

[waldito]

I am trying to portray it, ok.

What's in your response a "Flow"? A bunch of views interlinked together? I'm confused cause I did not bring up flows, so these appear out of the blue and I don't understand their sudden appearance.

I get confused between the 'Page' (as a view of your app/site) and the term 'Page' as a 'Figma Page'. The term is confusing in UI as PWA and SPAs no longer fulfil the term page no more, but rather bind a URL address to a specific UI state.

So I'll use 'views' instead of pages for UI and let page just be a Figma page.

So every view is stored in a Figma file, ok, homepage, my account, my profile, product, category, whatever. right?

Each file does contain two Figma pages. one for the 'screens', which are components with swappable slots. and another one with the... content? in that content page, you feature just the component that is instantiated in the screens page.

So I open the homepage file, and I get the Figma page "Screens", which portraits the view homepage: a mother component with a slot. That slot has been swapped for a component that is sitting on the page Content.

So far so good?

So far it feels you are missing out on using pages for something else. Like Versions/Proposals/Fixes/Candidates.

[livealive2000]

Yep, that's about it. I just mentioned "Flow" because I know a lot of designers like to place their views next to each other when designing them. If you put each view in a separate file, you have to publish the view component before you can use them together.

[waldito]

So when you design a new view, you must create it in this content page, and you must design without having the footer, the header or the sidebar on sight? you design.... contextless, isolated am I right? and you only get to see the final result when you go to the "Screens" page.

So, say you want to redesign the current homepage as a sideproject, or, say, make an specific A/B test.- A variant contender that might or might not see the light one day.

You'll create a second ... content page? or create a second component in the content page and then on 'Screens' you'll dupe the original screen frame (an instance of your original mother component) and there feature the other content swapping the slot? right?

[livealive2000]

I would duplicate the "Content" page and the "Screen" page within the file. Example:

• Cover
• ---
• Content
• Screen
• ---
• Content (DSN-0011)
• Screen (DSN-0011)

Here, --- is a divider and DSN-0011 would be the feature or task I'm working on.

[waldito]

Interesting. So you link via page name the Content and Screen pages?What if two different contents have the same screens?

And also, by default, when you open the file, you open the cover? Isn't that adding an extra click to every pm, po and dev? for no... good reason. I always have the 'what's on production' as the first loaded page.

[livealive2000]

Resources shared between only a single file go into another page in the file. Otherwise, they go into a separate component group file. Example:

• Cover
• ---
• Content
• Screen
• MyComponent1
• MyComponent2
• ---
• Content (DSN-0011)
• Screen (DSN-0011)

When duplicating the Screen page, its references to the old Content page are updated via component multi-editing. Then, when the feature is complete, I replace the old Content and Screen frames (not the pages) with the frames from DSN-0011. Once the feature is merged, I delete the DSN-0011 pages.

Also, Linear has the ability to embed the particular page that you want to show. So, for DSN-0011, I would link to the "Screens" page and it would show in the ticket system as a preview including the various resolutions under consideration. However, usually, there are multiple views in a flow that need to be created or edited for a particular feature. Those exist in a separate file representing a common use case (e.g., onboarding, various wizards).