Design Icons

[ghislaineguerin]

We need icons for the following concepts:

• [ ] Table
• [ ] Schema
• [ ] Database
• [ ] Record
• [ ] Multiple records (shown in the Record Page table widget)
• [ ] Exploration
• [ ] Search
• [ ] Record Search
• [ ] Add
• [ ] Delete
• [ ] Edit
• [ ] Save
• [ ] Cancel / Close
• [ ] User
• [ ] Data Types
  • [ ] Text
  • [ ] Number
  • [ ] Date and Time
  • [ ] URL
  • [ ] Email
  • [ ] List
  • [ ] Boolean
  • [ ] Money
  • [ ] List
  • [ ] JSON List
  • [ ] JSON Map
  • [ ] Other
• [ ] Warning
• [ ] Information
• [ ] Hint
• [ ] Filter
• [ ] Sort
• [ ] Group
• [ ] Link (action)
• [ ] Link directions
  • [ ] Regular
  • [ ] Reverse
• [ ] Inspector
• [ ] Action (in table inspector)
• [ ] "Opens modal" indicator (for table inspector actions)
• [ ] Key (for FK/PK)
• [ ] External Link
• [ ] Help tooltip icon
• [ ] Loading icon (inline)
• [ ] Loading icon (large)
• [ ] Undo
• [ ] Redo
• [ ] Extract
• [ ] Move

[seancolsen]

Before you go make all the icons, I'd like to be involved in reviewing the first couple of them, just to make sure the format works well. I've done a lot of work with SVG and have some opinions about how best to make icons.

[Dhruvi16]

Hey @ghislaineguerin! How have you been? Just saw this issue and seems like can be done independently with fewer reviews. Is this something I can work on?

[seancolsen]

Since more people are getting involved in this conversation I'll try to express some of my thoughts async. Creating icons involves quite a bit of tedious work and it would be great to get our process ironed out ahead of time.

I'm looping @pavish into this thread because he recently did some work, adding these new custom icons.

Here are some conventions that I would propose we adopt as we create custom icons...

• (A) When an icon design includes something resembling a line, the thickness of that line should be consistent with the thickness of the lines in all the other icons. Some design elements may not exactly be "lines", so this rule allows some room for interpretation.

  This means we need to establish (and somehow document) our standard line thickness.

• (B) All SVGs should be square. The design inside can have a slightly different aspect ratio if needed.

• (C) All icons should use one and only one path, and that path should not have any attributes other than d. Attributes like fill-rule and clip-rule, aren't necessary if you modify d appropriately. Modifying an icon to meet these requirements is pretty easy with Inkscape.

• (D) The path should use fill (not stroke).

  (We're already in conformance here due to our Icon component setting a fa-icon class on our svg.)

• (E) All icons should use a consistent viewBox. I would recommend 0 0 100 100 (because it's pretty intuitive), or 0 0 512 512 (because that's what FontAwesome uses).

  With a consistent viewBox, we can codify rule (A) into an exact number, making it easy to begin icon designs using stroke and then converting them to path.

• (F) We should take care to minimize the number of nodes and use straight lines where possible. This keeps the SVG size down.

• (G) Designs should include a small (and consistent) buffer between the outer edges of the content and the extent of the viewBox. For example, when I design icons, I usually set viewBox="0 0 100 100" and then make sure to include a 1 unit margin around my design, making my design no taller/wider than 98 units. This leads to slightly better-looking results in some cases. E.g. at certain zoom levels, some SVG renderers employ antialiasing that can appear to truncate the outer edges of round designs, as shown with our "exploration" icon here in Firefox.

  

• (H) Final path data should be optimized for size. Inkscape does a pretty good job with this via "Save as Copy..." > "Optimized SVG". Tools svgo are a little more powerful but trickier to use.

• (I) Within our repo, we should commit svg files for the original sources used to create each icon. This could include much more elaborate elements than just a single filled path. There could be groups, clones, and more. Then we'd also commit an "optimized" version of the same icon, with everything flattened and converted to one path. Finally, we'd put the path data into a .ts file, as Pavish has already begun doing in customIcons.ts.

  For now, this process can be manual. But we could eventually seek to automate it by programmatically "building" all our icons from their source files.

[seancolsen]

@ghislaineguerin, in looking over your list at the top of this ticket, I'm wondering: do you want to create custom icons for everything?

• If so, there will be many more to create than listed above. See src/component-library/common/icons.ts and src/icons/index.ts. There are currently 74 icons total.

• If not, then I think we could safely eliminate many of the entries above where we already have suitable icons.

[ghislaineguerin]

@seancolsen I don't know if we'll have enough time to create all of the icons if we want to get this done for the live demo release. I'm guessing that if we limit ourselves to follow the visual style of the current icons closely, we can get use a combination of the existing icons and some new ones.

By suitable, I'm assuming you mean icons that are consistent with the current icons, right?

[seancolsen]

@ghislaineguerin

use a combination of the existing icons and some new ones

That would be my preference too.

I'm assuming you mean icons that are consistent with the current icons, right?

What I mean is: your checkbox list at the top of this ticket includes unchecked to-do items for icons like Search, Add, Delete, Edit, Save, Undo, Redo, etc... and I would argue that the FontAwesome icons we've already selected for those concepts are suitable. It's not worth our time to create a new "Add" icon. I mention this because if we're going to parallelize this work (giving some to @Dhruvi16), then we ought to have a shared vision for the priorities. In contrast, some concepts within the app don't have a suitable icon yet because we couldn't find one within FontAwesome (e.g. Table Inspector, Record Selector). We should focus on those. If we're going to use a combination of the existing icons and some new ones, then I'd suggest paring down the to-do list at the top of the ticket so it's clear to people like @Dhruvi16 what we need.

[kgodey]

@seancolsen This issue is a draft (not ready for work), we're writing down icons as we encounter them in the designs. It's not meant to be comprehensive and the checkboxes aren't meant to represent "we need a custom icon for this".

I imagine the next steps before we mark this as ready for work would be: (1) ensuring the list contains all icons in the product (2) figuring out which icons we can reuse FA icons for and making that clear (3) having a final list of custom icons we need

[kgodey]

Moving this to the Backlog – this isn't critical enough to block launch.