
Latitude Design System - tosh
https://www.flexport.com/design
======
tenaciousDaniel
One thing I keep noticing about design systems is that they all look extremely
difficult to maintain.

On the development side, we all know that the more difficult/complex a unit
testing suite is, the less likely it is to be effectively maintained.

All design systems I see are art directed. You have these very nice visual
layouts showing each element of the system, with well crafted type explaining
each aspect of it. It isn't a _generated_ document; it's seemingly hand-
crafted.

So my immediate thought is: is this versioned? What happens if it's updated?
How should the changes at this stage propagate down to the individual teams
who consume this design system? Maybe I'm not seeing the whole picture, but I
have a hard time believing that these "design systems" are built for long term
sustainability.

~~~
mikeryan
Design Systems are much like Frameworks you can either formalize and document
the process or not but all this type of information has to live somewhere and
be communicated.

The hard part here is that now with the rise of alternative tooling like
Sketch, Zeplin, Figma and technologies like styled components, SASS, post css
etc - there's a pretty broad range of ways to pull all this together so some
of the implementation is going to be organization specific.

In general though we've found that developing design systems can greatly
increase our throughput on new initiatives without having to reinvent the
wheel on a lot of basics. There's some overhead but at least it makes for a
transparent way to manage communication of a design.

Of note there's a great site
[https://designsystemsrepo.com/](https://designsystemsrepo.com/) that is a
repo of a bunch of design systems. Great place to peruse.

~~~
tenaciousDaniel
When I look at design systems, it definitely _seems_ like a good idea. But
then when I take a step back and ask myself "what problem are we trying to
solve?" my answer is:

we need to communicate the intent, behavior, and visual attributes of an
application to (a) stakeholders for approval, and (b) developers for
implementation. This communication is expected to update over time and
potentially to several teams, though not all teams at once since they need to
update their own designs in response.

When I think about ^THAT problem, I ask myself "is what I'm seeing in a design
system the thing that Once And For All solves that problem?", the answer is
no. There's something that doesn't feel sustainable to me.

------
acrefoot
Is there more benefit to publishing a company’s design system than maybe some
recruiting benefit? Is it about giving back to the design community or
something IP/trademark related?

~~~
RickS
Depends on the company.

Some design systems are comprehensive, mature, and general enough that they're
suitable for use by hobbyist devs or smaller orgs that want attractive,
versatile UI components but don't want to spend effort spinning up something
of comparable quality internally. Ant design comes to mind as one I see
frequently.

The other benefit is companies that offer extensive third party integrations,
like saleforce with their Lightning design system. By making the DS available,
they let third parties build plugins that feel like a part of the platform,
with high quality tools. This helps negate a lot of common problems with
platform plugins that are ugly/unintuitive/broken.

Design system tooling (as opposed to UI component libraries) is more of a
traditional open source / giving back dynamic. Theo from Salesforce and Style
Dict from Amazon are widely used as part of the infrastructure underlying
smaller companies' internal design system efforts, without going so far as to
influence specific component implementations or visual styles. It's akin to FB
and google opensourcing data infrastructure tooling.

------
kaivi
Finally, a decent table component! Just what I was looking for my new project.

A nitpick concerning slow animations: there is no place for them in a modern
enterprise app.

~~~
dmnd
As you can see in the readme, we haven't made any accommodations for external
adoption — the system is very opinionated at the moment (i.e. themes, styles,
types).

But we were thinking perhaps we should spend some effort making it easier for
others to use <Table /> elsewhere. How close to usable is it for your use
case?

~~~
kaivi
It is really fine as it is for me, the custom styles don't really matter for a
B2B app I am working on. Just add an InlineEdit mode to a Table, and it will
be better than any OSS table component there is today!

One thing about inline-editable components and tables. As a former office
drone and a part-time speditioner, I believe that such components must be
tabbable, and an ideal editable table should try to mimic the desktop
experience. Office workers spend thousands of hours in backoffice apps,
watching 0.3s animations and aiming with a cursor, but they never complain
because they don't know any better.

Just to demonstrate a different InlineEdit, here is a demo of a lib I made
several years ago. It worked great with tables and card views:
[https://kaivi.github.io/riek/](https://kaivi.github.io/riek/)

Also didn't your former colleague write up this post on data tables in 2017?
It was trending here yesterday. Looks like a lot was already implemented back
then: [https://uxdesign.cc/design-better-data-
tables-4ecc99d23356](https://uxdesign.cc/design-better-data-
tables-4ecc99d23356)

------
DrinkWater
[https://github.com/flexport/latitude](https://github.com/flexport/latitude)

------
akrymski
Something is broken with the web when every company across every industry
feels the need to produce its own design system.

~~~
RickS
Are there changes to the web that you think would lift that burden, or make
design systems less necessary?

Two major drivers come to mind in terms of DS adoption:

1) Giving teams a common toolkit of resources so that they can design
consistent experiences without having to independently implement and maintain
the same components.

2) It's really trendy. It's the designer equivalent of moving to serverless,
or nosql years ago, etc etc. Small teams do it because it's cool and fun
despite not necessarily feeling the enterprise-scale pains that originated
some of the practices.

(I would not put flexport in that category. They've got an extremely data-
intensive software, and a good component lib helps a lot there)

~~~
akrymski
Sure, the HTML standard needs to go - it was designed for hyperlinked
documents, not software.

Components should be provided by browser/OS vendors with a standard look and
feel, the same way desktop software has been written for decades. React Native
is a glimpse of what HTML of the future will look like.

Flexport is a logistics company. They aren’t in the business of selling
software.

What we’re doing right now is like the first GUI desktop apps - lacking
consistency because there was no solid platform every designer reinvented the
wheel.

~~~
akrymski
Thank god the browser provides the text input component otherwise every
designer would have their own take on that too.

------
arh68
On /design/styles, s/We belive/We believe/. Why the backticks everywhere? It's
like somebody s/'/`/g'd the whole page. Also s/prop dependancy/prop
dependency/. Not found on /design/components/Anchor. Not found on
[https://github.com/flexport/design](https://github.com/flexport/design), as
DrinkWater has noticed w/ the correct link.

EDIT: my bad, INTERNALS is just a FB thing, I've just never noticed

