Tracking UI design progress

[graphicore]

These are a first round of design mockups created by @guidotheelen

dashboard mockups.zip

Also, same files: https://drive.google.com/open?id=1b-VBfpQhjhMuBOaIcfpxL2QEsFU08flH for better browser access.

[davelab6]

Quick notes:

• Some kind of design system off the shelf is good to accelerate progress, and probably a CSS-only Material Design one would be ideal. This should not be related to the Google Fonts visual design; eg, rounded corners on inputs are a "Google Material Theme" thing, and should not be used here. This is not an official Google product, it is a libre software project that Google Fonts team is giving financial support towards development.

Home

• Logo on right and login on left is weirdly inverted, should be the opposite

• The drop zone visual design is nice, but the whole page should be the zone (like https://dinamodarkroom.com/gauntlet/ or http://typetools.typenetwork.com, not like https://wakamaifondue.com ;) so I don't have to have a browser "download" the file I dropped into the windows and then hit the back button and reload the whole page and then hunt for the dropzone and drop it again... :)

• The explanatory text will mostly be ignored by users, but to try to prevent that, the page could have the drop zone floated left, so the text is to the right of it.

Report

• Progressive disclosure of process is good.

• Progressive disclosure of each each is good, but there should be an 'open all' button that completely unfurls the whole thing so that Ctrl-F works to find something

• The black background element in monospace should be more friendly, and extraneous/duplicate detail (eg 1. FAIL and [code lacks-git-url]) should be cut, so the output feels more friendly and less inscrutible

• The grouping and order of the result category tab bar should be improved to communicate priority more clearly - failures are very important, warnings are sort of important, while skipped and passing are not very important, errors when 0 are not at all important.

• Errors when non zero likely each require FontBakery developer attention so should appear in a special way (like a big button that says "this FB run had an error, click here to report it", and if logged into Github then use something like https://github.com/sindresorhus/new-github-issue-url to file an issue straight away, perhaps with a 'needs triage' tag or something..)

• The default view to view all checks, suggests each result should then indicate which file(s) it applied to, to prevent the user seeing the same fail/warn over and over again across the project.

Dispatcher 1

• Is "Choose an existing family" keyed off the sheet we use to track upstreams' github URLs? Using the same sort of 'issue tracker filing by URL' technique, can we allow users who submit new info into this form to submit it to us somehow - perhaps using the Google Sheets Form? Per https://medium.com/@dmccoy/how-to-submit-an-html-form-to-google-sheets-without-google-forms-b833952cc175 it looks possible to get GSheets to accept form input from HTML - so that we don't need to keep asking users to resubmit it over and over again?

• The 'macro' user flow of the dashboard is that people will run it in a continual "sandbox mode" loop, repeating the process while doing incremental engineering improvements, and once they are happy with being in a 'release state', they will run "production mode" and make the PR to the main GF repo once. I think that should not be 'two modes' actually, it should be one mode, but the "make PR" stage should default to "pr to my gf repo fork (github.com/username/fonts)" and then have a 'red button' option to "pr to the real gf repo".

Dispatcher 2

• The priority of the information on this page seems to me to need more work :)

[davelab6]

The end of the FBD dispatcher process should be a big gold-star/red-ribbon "congrats!" page... "Yes! you have made a PR to the real GF repo, your PR link is github.com/google/fonts/123456789, subscribe to that issue to follow the discussion of your submission (here's how! LINK), and fontbakery.host.com/leaderboard#family-name is your link to your row in the 'FBD Leaderboard' Progress Table page to follow the progress of your family all the way to the GF production API"

And then fontbakery.host.com/leaderboard#family-name would open like this link opens to highlight the row indicated by the URL fragment.

And then on that Leaderboard, if a repo has been successfully pushed to production recently (TBD) and has an update where the FB checks that passed last time did not regress, and no new checks FAIL or WARN, then it should be really fast to make a PR.

And we'll have the kind of thing I described as the vision in the the Typecon 2018 presentation deck

[davelab6]

I wrote,

I think that should not be 'two modes' actually, it should be one mode, but the "make PR" stage should default to "pr to my gf repo fork (github.com/username/fonts)" and then have a 'red button' option to "pr to the real gf repo".

Lasse said on chat,

Actually, viviana likes the sandbox concept, it’s comforting to her.

From a cybernetics point of view, i view the purpose of the FBD project as a whole to be winding tighter and tighter the process loop of making updates to families a foundry releases (in this case to GF.)

So, I think a graphic design that shows "you are in sandbox/drafting mode, nothing is final" can communicate this, while not making a "second loop" part of the user flow.

The ubiquity of a 'back' button, left of a "next" button, would also help communicate that the process is not one-way-gated.

[RoelN]

Thanks for the feedback, @davelab6, and the between-the-lines feature request for Wakamai Fondue ;-)

These were early concept sketches to wrap our head around the process, and we have in the meantime addressed most of the points you mentioned. We want to make this as much of a linear process as possible, with indeed a clear end-of-process indicator and a big fat red button to actually submit. We also want to limit user interaction ("asking questions") to the beginning and end of the process, so you don't have to keep checking the page in case the process needs something from you.

The current plan is to implement this in the most basic HTML/JS setup possible, allowing you to go through the process in easy steps, then adding flair/UX/design/candy/paint/etc.

@guidotheelen and I are working hard on this and will report back here with progress! :)

[graphicore]

Re: Sandbox

There was another reason for Sanfbox btw: feature branches. Viviana asked explicitly to work from a feature branch in Sandbox, pre PR to the master branch. To keep sources (the repo where the upstream fonts come from with it's setup) for this kind of workflow unconfused with those that eventually go into production, the "sandbox" is a handy separator.

[davelab6]

Thank you both!

I just ran fontbakery-dashboard dropper on a Japanese font (https://github.com/satsuyako/CherryBomb) and it seems the 'kingpin' check of filenames being canonical should have a very large graphic FAIL message, and @felipesanches please note that the check result should let users know the primacy of this check and that it means a bunch of checks are skipped. Also, I guess it is possible to tell the user more clearly what to rename their file to, in the case that there is only 1 file in the family set.

https://fontbakery.graphicore.de/report/23364f76-abba-4152-807d-1cbb1c41c8f6

So, I quickly renamed the font file to the canonical name and reran the checker:

https://fontbakery.graphicore.de/report/246f2d0d-a7da-44b3-a0ed-dcd6d41a3ab4

What I see is that some WARN results appear before the FAIL results, but all FAIL results are higher priority than any WARNs and so the ordering should be addressed.

Additionally the checks have some logical groupings - a few are about copyright/licensing, a few are about family/style naming, a few are about vertical metrics, a few are about fiddly metadata... - and those should be grouped too.

[graphicore]

@davelab6 this much more than just putting some CSS on it.

[guidotheelen]

Hey Dave / Lasse / Roel,

Thanks for all the feedback so far. Here are the new mocks. (Keep in mind that the design can change still. So don't focus on that too much. Probably Google Material Design will give us a lot of standardisation out of the box)

Home

• Here I wanted to introduce a bit of an old American kitchen/oven theme. So I created this responsive oven as the dropdown area. The whole page could be a dropdown.
• If you need more information, the "What happens to my font" link can be clicked. This makes the page scroll down to the information section of the page.
• I removed the chefs hat as a logo in the header. The text logo alone could suffice here. But this is just an idea. I don't want to discredit the logo.

Report

• The title of the report says what's going on within the report.
• The progress bar is more clearly now.
• At first only the most important checks are displayed (Error, failure, warning) The rest is hidden till the "Show all checks" button is clicked.

Dispatcher Step 1

• Here I added the different steps already. So the user can see what steps are next.
• The icons have a baking theme, just to make it a bit more playful.
• If the font you want to update is not in the list. You can make a request to add it. (This is different from the current workflow. Where a user adds the font himself)
• We want make all the decisions on this page, so the next following steps only contain verification/approval questions.
• All the checks are mandatory for a production PR. So if one of the tests is not selected. This is clearly displayed above the "Start process" button.

Dispatcher Step 3.1

• These tasks are fired off automatically when entering this step.
• The additional info (technical process information) can be found in the timeline. (Dropdown in the bottom.)
• The little yellow tag displays if the task is still running.

Dispatcher Step 3.2

• When the task is finished you need to make a choice if you want to continue or let the process fail.
• When there are fails and still want to continue with the process, you need to add a note. Why this fail is not severe enough to issue.

Dispatcher Step 5

• The 'Done' cookies are not really in the American kitchen theme, so those probably have to go.
• The other steps are still available for the user. In this way the provided information is still accessible.

I'll make an other mock of the Preview step. Here we really want to make clear to the user is the action is directed towards production or not. (By doing this we can lose the Sandbox/Production mode)

Let me know what you guys think of the new mocks! I can't wait to get going in code!

[graphicore]

I just had a call with @guidotheelen to discuss the current iteration of the UI mock ups. He and @RoelN do a good job of simplifying the user experience. Though one thing that I think we need to discuss is indeed the infamous sandbox mode and maybe some other details/decisions.

While I was writing this @guidotheelen posted his mock-ups. Now I'm going over some of the text again and include info from the post above.

Adding a new family

A lot of that stuff is done in the startup of a dispatcher process, only to the end, that someone, with the rights writing the spreadsheet, eventually has to add the repository data to the spreadsheet that we use. I'd like to cut that short and simply file an issue directly on the fontbakery-dashboard repo via the dispatcher. Then someone with the right permissions (writing the spreadsheet) and knowledge should make sure the entry is added and working. When done successfully, the process can be started and it proceeds automatically to the manual file package evaluation, cutting out like 2 screens of form input and evaluation loop. I don't think we can skip having the user check the files package completely, as it's not always clear what to expect of the file package contents, and thus it's hard to asses it automatically. If e.g. a font-file is missing from the files package, e.g. because there's a typo in its file name, we would probably run through all of the process without explicitly noticing that.

• If the font you want to update is not in the list. You can make a request to add it. (This is different from the current workflow. Where a user adds the font himself)

That's the same point. The request would be made as an issue, probably on this issue tracker, via a form in the dispatcher. But, no process would be created from that.

The sandbox

The longer I think about it, the more I realize that the main feature of the Sandbox is not that users feel comfortable with trying things out. The actual feature is enabling the feature branch workflow. When working on a feature branch e.g. add-greek-skript of the family abeezee the user wants to check it's evaluation result before creating a PR to the actual upstream branch, e.g. abeezee/master. At the moment, we have two different list of "sources" (repository/branch etc. setup) for production versus sandbox, and in sandbox we can have multiple entries for the same family:

My argument now is, that there's a value for us in having the upstream of a project defined as a single source, hence, it should not be possible to create a PR to google/fonts using the dispatcher from a feature branch source. Otherwise, we end up allowing multiple upstreams for any project, creating eventually confusion. I think the discipline, of having just one upstream source defined, that we enforce upon the projects is acceptable, as it is the common way of handling this, as well as it is a good way to make our database less ambigous. There can be many "feature branch" sources in different repositories for each family at any time.

So, given the screenshot above. We could have just one list of "Sandbox" and "Production" sources mixed together. However, choosing "ABeeZee" will allow you to create PR to google/fonts, while choosing "ABeeZee:Graphicore Fork" should not act as an "upstream" and hence not enable you to create a PR to google/fonts. It wouldn't be a big deal to change the upstream of a family if it is needed to move either (file an issue here), but I think the value of having it explicitly unique is good for our data hygiene.

In the mock-up above, in Dispatcher Step 1 we can choose which tasks to run. This is a new suggestion in this round. I think that's maybe nice, and if we cut down the files package task to just a single assessment (described above) we can really move quickly to lunching the workers. I'm not fully convinced if choosing up-front is good or if that is removing the decision whether to run the task to far away from actually running the task.

• We want make all the decisions on this page, so the next following steps only contain verification/approval questions.

I don't want to make a bike shedding out of this, but how do we know if this is actually desirable? I mean the goal is obviously to make the decision-making easy, however, we shouldn't forget that we're asking the users only for decisions that are too hard to answer automatically. The select-inputs after checkboxes for diffenator and diffbrowsers plus the line "All the tasks are mandatory for a production PR" are from my feedback previously today, so is this remark a reaction:

• All the checks are mandatory for a production PR. So if one of the tests is not selected. This is clearly displayed above the "Start process" button.

(Offtopic, wording @guidotheelen: we use "check" for Font Bakery checks, "test" for unit tests and in here maybe "task" or "tool" for running these QA tools. I suggest: "All the tasks are mandatory […]." But that's open for discussion.)

Here we're back again to sandbox vs. production. I like the idea, that for a feature branch worklfow we can run e.g. only one tool. But, why should we allow a PR to production if we didn't run all of our quality control tools, it totally defeats the purpose. Of course, not without an exception: diffenator if there's nothing to diff against, because the family is a new on-boarding rather than an update, it's cool to skip, but I'd like to see that decisions made explicitly and best backed up by a comment why it is cool to skip that task.

For the other cases, these select menus allow for cases where:

• We just want to compare the update with the current version served via the GF-api.
• The family is not yet updated in the GF-api, but a version has been merged into master and we need to compare with that version. (We can at the moment run these tools multiple times with different comparison sources, the mock-up removes that option currently).
• Compare with the upstream version, this currently probably only makes sense when the source is not the same as the upstream version, and indeed this option is only available in what is currently the sandbox mode.
  • for diffbrowsers: create only previews and don't compare: again only applicable if this is an on-boarding in contrast to an upstream.

One point I want to make here is: we ask people these questions because it is hard to answer them automatically, and hence, removing these decisions is not necessarily the right thing to do. Maybe rather add more information, like the list I just wrote above, inline accessible (maybe via an :information_source: icon) next to the question, could help making those decision from an informed perspective.

The other point I want to make, no matter how we call it, sandbox or not, we shouldn't be tricked into believing that all processes are equally qualified to conclude a quality assurance procedure before putting the results into production. Hence, from some processes it should just not be possible to create that production PR. That would effectively be the sandbox again, but maybe inexplicit and only visible much later in the process. I'm not convinced that's a good thing. That line of warning in the mock-up is a good start, but we could as well put a shovel and a sand-shaper on the top as soon as we know that it won't qualify as a production process.

Sometimes, by shutting out decision making, we also reduce versatility. I don't know if that's a good thing, but it could narrow the general usefulness of the dispatcher a lot.

Order @davelab6:

Lastly:

What I see is that some WARN results appear before the FAIL results, but all FAIL results are higher priority than any WARNs and so the ordering should be addressed.

and:

Additionally the checks have some logical groupings - a few are about copyright/licensing, a few are about family/style naming, a few are about vertical metrics, a few are about fiddly metadata... - and those should be grouped too.

Either you group logically (i.e. by section, maybe add a group heading) and order within these by LOG-level (and then maybe priority) or you create a mess where you replicate all section groupings per Log-level. Ordering by LOG-level first IMHO should as well get rid of any section grouping information as it's too fine grained to make sense to anyone. However, ordering by section first will lead to some WARNs to appear before some FAILs.

[davelab6]

Rod defined 4 levels of change for each update. When users make a PR, they should certify which level their PR will be treated as by the downstream recipients of that PR. It may be possible to autodetect these levels, or provide a smarter default, but to be safe the default should be 4 (the worst) and users should have a very clear "big red button" UI to change the levels.

1. We anticipate users - even experts - can't tell the difference

2. Shapes change a bit, some users might notice, metrics don't change

3. Shapes & metrics change but not in a way anticipated to cause major issues (e.g. not significantly wider)

4. Shapes & metrics change, in a way anticipated to cause major issues. In particular, significantly wider (so text will fall off buttons, etc)

Shape changes and metrics changes could be split out, too

[davelab6]

@m4rc1e do you see any simple ways to set a better default for this?

[felipesanches]

It feels to me that these 4 combinations are actually 2 binary choices. So maybe the user interface could be 2 mandatory simple questions that have to be answered (by clicking answer buttons perhaps) instead of one single "big red button" with somewhat more complex text that might end up being ignored.

[davelab6]

I agree a simple quiz format might work well. How would you phrase the questions and answers?

[davelab6]

Rod also noted, shape changes and metrics changes could be split out

[felipesanches]

I agree a simple quiz format might work well. How would you phrase the questions and answers?

Question 1: Does this submission include changes to glyph outlines?

• No. Absolutely no change to glyph outlines.
• Yes, but very subtle.
• Yes. Likely to be noticed by average users.

Question 2: Does this submission include changes to font metrics?

• No. Absolutely no change to font metrics.
• Yes, but very subtle.
• Yes. Likely to be noticed by average users, potentially affecting the layout of user interfaces.

[felipesanches]

@guidotheelen I have seen your posts now and I gotta say that I love the way you organized it all. Super cool!

I have a few comments to make (and listed below) on the portions I disliked, but please be aware that the overall work you've done has been pretty great in my opinion.

objections:

• We have font "checks" instead of font "tests" (there's an underlying technical reason for that as something else in our code infrastructure uses the name "test")
• In the past we used check numbers, but recently we started adopting keyword-based check-IDs. I do not like to see the "Check number" portion of the UI since it may re-introduce the habit of referencing checks by numbers. Also, in this case, the numbers may be different for the same check across different runs (or with different font families), so using these numbers could lead to confusion when dealing with bugreports.
• The oven concept is super cool and I think it must stay. But I would tweak the chrome effect on the metal portions to make them less artifical. It hurts a bit on the eyes, specially the linear gray gradients. Maybe it should use some small PNGs in there for a more realistic feel. No need to be super realistic, by the way! Just a tiny bit less artificial would already help. And I know it is just a concept for now and can be tweaked later, of course.
• I'm not sure what you mean when you say the cookies are not aligned to the American kitchen concept. I think it fits well. But maybe I lack cultural background. By the way, there are choc-chip cookies being cooked by American astronauts on the International Space Station on a space-grade oven right now! :-D https://youtu.be/AQxRy323Sr0

[guidotheelen]

@graphicore Thanks for the detailed review. This really helps me to understand the system better! I'm just going trough some remarks you made:

The request would be made as an issue, probably on this issue tracker, via a form in the dispatcher. But, no process would be created from that.

I think this is way better than the current workflow! But how does a user know when he's able to select the new font family in the dropdown?

The family is not yet updated in the GF-api, but a version has been merged into master and we need to compare with that version. (We can at the moment run these tools multiple times with different comparison sources, the mock-up removes that option currently).

This is a feature we definitely want to keep. Maybe we can add an option in when the task is finished. -> Compare font against other version.

One point I want to make here is: we ask people these questions because it is hard to answer them automatically, and hence, removing these decisions is not necessarily the right thing to do. Maybe rather add more information, like the list I just wrote above, inline accessible (maybe via an ℹ️ icon) next to the question, could help making those decision from an informed perspective.

This is a good one, the choices are not self explaining at the moment. Someone with a lack of technical knowledge would have a hard time making a choice here.

We could have just one list of "Sandbox" and "Production" sources mixed together.

Would be really cool!

That would effectively be the sandbox again, but maybe inexplicit and only visible much later in the process. I'm not convinced that's a good thing. That line of warning in the mock-up is a good start, but we could as well put a shovel and a sand-shaper on the top as soon as we know that it won't qualify as a production process.

An other option could be to let the user know his process does not yet confirm the Production procedure within the 'Preview' step. When the user decides to still run a specific task he excluded in the beginning, the user is still able to convert it to a production release.

@felipesanches Thanks for your remarks! We are getting somewhere! 🏃‍♂️

We have font "checks" instead of font "tests" (there's an underlying technical reason for that as something else in our code infrastructure uses the name "test")

In the past we used check numbers, but recently we started adopting keyword-based check-IDs. I do not like to see the "Check number" portion of the UI since it may re-introduce the habit of referencing checks by numbers. Also, in this case, the numbers may be different for the same check across different runs (or with different font families), so using these numbers could lead to confusion when dealing with bugreports.

Good points, will make sure these are implemented.

The oven concept is super cool and I think it must stay. But I would tweak the chrome effect on the metal portions to make them less artifical. It hurts a bit on the eyes, specially the linear gray gradients. Maybe it should use some small PNGs in there for a more realistic feel. No need to be super realistic, by the way! Just a tiny bit less artificial would already help. And I know it is just a concept for now and can be tweaked later, of course.

Check! The oven still needs some attention.

I'm not sure what you mean when you say the cookies are not aligned to the American kitchen concept. I think it fits well. But maybe I lack cultural background. By the way, there are choc-chip cookies being cooked by American astronauts on the International Space Station on a space-grade oven right now! :-D https://youtu.be/AQxRy323Sr0

Haha that's cool! Yeah maybe it's good for now.

@davelab6 I added the questions in the first dispatcher page. Is this the right place?

[vv-monsalve]

Hi to all! I’ve read the thread of discussion and I'll try to organize my thoughts on it:

Sandbox (or selected name)

---

I still support the idea of having a “QA check” mode in an independent way of the Production one, for all the mentioned reasons, that I would summarize as a Pro and Cons list:

PRO’s

• To have a “safe environment” to run the checks and tasks of the Quality Assurance step on a continual loop while doing incremental engineering improvements before going “production mode”
• To enable the feature branch workflow, having multiple source entries to check different repositories for the same Family
• To have the upstream of a project as a single source to preserve this:

the discipline, of having just one upstream source defined, that we enforce upon the projects is acceptable, as it is the common way of handling this, as well as it is a good way to make our database less ambiguous.

• To have the new proposed possibility of running all the tools or only one of them, which I found really useful in this "QA/Sandbox" mode (leaving it clear that to pass all the checks is required before going to PR, maybe in a note or on a floating window once the user reaches this interface step). When using the Dashboard I've wished to have this option after reaching a point where I just needed to run BrowserDiffs, knowing the FB checks were already ok, and of course, because they were new fonts so there was nothing to diff against on Diffenator tool.

• To have a more clean list of projects in the Production Mode, without the possible noise of many entries for a project that could lead to confusion. Even if there is a single list for “Sandbox” and “Production” sources mixed together and then the user picks a feature branch, and if we preserve the logic behind a "single source" then the user will not be able to make the PR from that feature branch e.g. add-greek-skript, so it would be necessary to go back to the beginning of the process anyway, to change the upstream branch this time e.g. abeezee/master, which is, by the way, the standard way of working with branches: to eventually merge to a single “master” one. Thus from what I see the «“second loop” part of the user flow» would be still needed.

CONS

• So far, I think only about the “second loop” in the user flow

Finally, in any case, whether is a unique mode or not, some explanatory text would be necessary to frame what the user will need to review when checking all the results of the tools. Fonbakery already has its system of Fails and Warns texts with rationals, but the user will need to know what would be the key factors to pass or fail on the Diffenator and BrowserDiff reports (particularly on an Update process).

---

Mockups

---

FB Home

• Although I found the American kitchen/oven cute, I believe its a little distractor. I would advocate for a simpler and more neutral interface, maybe more related to what typography designers are more familiar with, so it could be more intuitive or comfy for them as users.

• One thing to solve in the oven would be what happens when the family is more complex and therefore the list of fonts is larger. e.g.:

• The explanatory text of "what happens to my font?" could link to an "About" page, that the user can also reach from an "About" button on the top main menu.

FB Report

• The checkbox next to Family and each weight title is not clear if it is something you can choose (which is the idea of a checkbox).

Regular button behaviors like "over" and "active" with a clear indication on which one is currently selected or "on" could work best, as well as prioritize what is the first result displayed when the report is opened. In the currently used report, it's not immediately clear which one and why is it the first report showed (pic below), improving this would be really helpful to review the results.

Besides, one of the best things about this online FB report is that it includes some Family checks that the command line checks don't (e.g. Caladea didn't report any Fail after the local checks). It would be great if the user lands on the Family report to start there.

• I would vote to keep the current system (not necessary the style) of icons to what some users are already familiar with are really explicit, like the flame for Fails.

• Hierarchy in general on this page could be reinforced, maybe from typographic resources ;)

Dashboard 1

• The possibility for the users to "Register a font" as it was shown in the first mockups I think would be useful, especially if the option of a GFSheets to accept form input from HTML mentioned by Dave is possible. Otherwise, we could still use a regular GFForm to do that, which we are certain that works with GFSheets so new fonts could be easily submitted by users.

• A short explanation about each tool with links or the ℹ️ to display more information (like the parameters to key factors to check) could be below the title of the tools.

• In Production mode, the option to not run Diffenator with reasoning on why should remain abled, to upload a new font (as in the current "Finish this task" action with the "Skip! Please explain" option)

Dashboard 3.1 / 3.2

Traffic light colors here are useful to visually communicate the state of the process. Therefore, the use of the same colors should be avoided on other UI elements like the icons for the Steps. For those other uses, the color scheme could be more related to the Font Bakery blue palette. It would reinforce the wayfinding leaving clear the hierarchy about what is process information and what is context information.

At the same time, the structure for that sign should be the same. In this case, if it's the little tag as the yellow ones to make it clear to understand as an indicator of the state of the process. Otherwise, using it as a background color of a title would seem as an identifier of a type of task and thus it creates a hierarchy conflict. E.g. here the name Diffenator stands out over Fontbakery, which is the tab on which the user is.

Review Info

I'll leave some comments on the previous mockups in case they can help for the new version

If this note information comes from the “Note” field on the previous interface, it would be more evident to suggest its content with a grey text example, e.g. “The update is created to …. Otherwise, it's not clear what text could be written there and would be ignored in most of the cases.

The "Thank you" message in the current version is a friendly one that could be kept and left above the "Process information" title.

---

Last but not least, to provide some instructions on how to use the Dispatcher or other explanations that could be needed or useful, they could be given in a system of floating windows like in https://typetools.typenetwork.com/ ( pics below)

[graphicore]

Thanks a lot everyone for the feedback!

@guidotheelen I'll answer your questions below:

I think this is way better than the current workflow! But how does a user know when he's able to select the new font family in the dropdown?

The users have to log in with their Github handle and the issue will be created with their account. So when the issue is commented or closed, they will be notified via Github.

This is a feature we definitely want to keep.

I think so, yes, I expect users to occasionally iterate quicker than we can put things into production. It should make sense in some cases to compare rather with GitHub than with production.

Maybe we can add an option in when the task is finished. -> Compare font against other version.

Yes, we could run both diffbrowsers and diffenator "speculatively" with the "best" source (I suggest we have an ordered list of sources and pick the first that can provide files, i.e. that has an entry for the family name). When that's finished, the user could still run with another source.

[guidotheelen]

Thanks for all the feedback!

@graphicore good remarks!

Yes, we could run both diffbrowsers and diffenator "speculatively" with the "best" source (I suggest we have an ordered list of sources and pick the first that can provide files, i.e. that has an entry for the family name). When that's finished, the user could still run with another source.

This could look something like this:

@vv-monsalve Thanks a lot, really useful feedback here!

Although I found the American kitchen/oven cute, I believe its a little distractor. I would advocate for a simpler and more neutral interface, maybe more related to what typography designers are more familiar with, so it could be more intuitive or comfy for them as users.

Would love to still use the oven, but in this state it's a bit too much. I'll create an other less in you face version.

One thing to solve in the oven would be what happens when the family is more complex and therefore the list of fonts is larger. e.g.:

We could make the oven responsive. So is scales when more fonts are added.

The explanatory text of "what happens to my font?" could link to an "About" page, that the user can also reach from an "About" button on the top main menu.

We already want to include a link to the docs in the nav bar, but we still want to encourage users to read the explanation. I think it could work to just place it underneath the explaining graphics.

The checkbox next to Family and each weight title is not clear if it is something you can choose (which is the idea of a checkbox).

When the report is opened, all font weights are displayed. Only if a user want to limit the results he can edit the selection with these checkboxes.

I would vote to keep the current system (not necessary the style) of icons to what some users are already familiar with are really explicit, like the flame for Fails.

Good idea, will look good as well!

Hierarchy in general on this page could be reinforced, maybe from typographic resources ;)

Good call, this is a wireframe that slowly transformed in a design mock-up. Using Material design will improve this when we move on.

A short explanation about each tool with links or the ℹ️ to display more information (like the parameters to key factors to check) could be below the title of the tools.

+1

Traffic light colors here are useful to visually communicate the state of the process. Therefore, the use of the same colors should be avoided on other UI elements like the icons for the Steps. For those other uses, the color scheme could be more related to the Font Bakery blue palette. It would reinforce the wayfinding leaving clear the hierarchy about what is process information and what is context information.

Tried it out in the image above. Good call!

The "Thank you" message in the current version is a friendly one that could be kept and left above the "Process information" title.

I don't think this is the right place, but we still could use a "Thank you" message somewhere.

Last but not least, to provide some instructions on how to use the Dispatcher or other explanations that could be needed or useful, they could be given in a system of floating windows like in pics.

I this this is a bit too invasive. If we explain the expectations and possible user interaction in the right way, we probably don't need it.

[vv-monsalve]

@guidotheelen you are fast :D

Tried it out in the image above.

Yeah, it looks clearer now I think. Another suggestion

It could be also good to keep the step name "Quality Assurance" as a title here, as well as in the previous interface

[guidotheelen]

@vv-monsalve Ahh good ideas! Thanks 👍