elements of design

peter sikking edited this page Sep 27, 2017 · 71 revisions

This page lists the first, rough building blocks of the design. With that the Metapolator project is out of the dark and the interaction design goals start to be realised. But this is not a complete solution; details are lacking; drawings are illustrations, not building plans; and the interaction is not exactly specified. That is for a later phase in the project.

So enjoy the fact that you can watch interaction being created ‘out of nothing’ and that you can plan with what you see here. Thanks for your patience where it comes to the last detail.

The working UI demo page offers details about how these building blocks can be simplified and prioritised for implementation.

960px comps

Designing for the (effective) minimum viewport size of 960px wide, 700px high is tough, but we want this to work on 1024x768 laptops. Here are the wireframes for the three views we have structured the UI around—

Parameters view:

Design Spaces view (note: the data of the different panels is not 100% consistent):

Fonts View

and the complete panorama:

overall structure

updated: read the first exploration below, or jump to the update.

Let’s develop an overall structure for the user interaction; a global plan for where everything in Metapolator ‘lives’. All the functionality we have to pack, even for v1.0, does not fit on one screen; different departments need to be created. But we also want to create a sense of continuity for users, not just a collection of screens and panels.

We can observe the following:

  • the masters form the connection between the world of skeletons & parameters, and the design spaces.
  • the instances form the connection between the design spaces and real font (families).
  • the two statements above have in common the design spaces, they connect masters to instances.

With these three connecting elements, we can chain four departments together, their working titles are:

  1. Parameters
  • Design Spaces
  • Metapolation
  • Fonts

Giving everything its place it looks like this:

notes, from left to right:

  • parameters is where the cascading parameter system is displayed and edited (driven by context of the next section); here also the global, project parameters can be found (always, heh);
  • character range or specimens are set up here and form the working context for editing a whole master, a glyph (range), point(s), lines(s), or vector shape(s)—all via the parameter section or via direct manipulation here.
  • masters and adjustment masters are managed here and drive either the character range or specimens section or are input to the next two sections.
  • (adjustment) master sequences, are managed here.
  • design spaces set up here from the master side; worked in from the instance side; in the lower half character range or specimens can be evaluated, deeding on the master(s) or instance(s) highlighted.
  • metapolation sliders supplement the more visual and explorative design spaces with precise input.
  • (families of) instances are managed here.
  • font (family) mapping is managed here, large-scale font export takes place from here.
  • metadata is maintained and assigned here to the font (families).
  • beyond this, in the future kerning and hinting will also find a home at this side of this tableau.

Driven by the choice of department (Parameters, Design Spaces, Metapolation, Fonts) the viewport slides left or right, showing the continuity between these departments:

(yes, for R-to-L language UI localisation, the whole order of these sections needs to be reversed, because its sequence is a forward/backward order in reading direction)

and then there were three

Encouraged by a constructive challenge from Simon and Wei, I have redesigned the panels, merging the middle two. Now we have three departments:

  • Parameters
  • Design Spaces
  • Fonts

here with the viewport:

the transition time for the sliding is 700ms.

individual department views

Parameters:

default column ratios: 3 : 10 : 3

On the right, manage (adjustment) masters and select which ones to work on—also master sequence management is integrated here; review in the middle, directly manipulate and possibly refine the selection to glyph(s) or sub-glyph(s); review and work on the parameters of this selection on the left.

Design Spaces:

default column ratios: 3 : 10 : 3, horizontal divider at 50% height

Place (adjustment) masters on one or more design spaces—to explore, or to set up instances in a controlled way; create and manage (families of) instances and adjust them in the design spaces; review (a mix of) masters and instances in the sepcimen.

note that the activity of loading some existing fonts; setting up a design space; exploration of this space using some instances; evaluating and/or quicky exporting them can all be done here in this view.

Fonts:

default column ratios: 3 : 1 : 12

Mark (families of) instances for font export; manage metadata and assign to font (families).

quick notes:

  • it will not be required to set up and navigate to the Fonts section to get a font out of Metapolator—for a quick try-out there will be quicky font export available for individual masters and instances (& co);
  • future support of kerning and hinting will find its place in the Fonts view (location-sharing with metadata).

sizing rules

note: all talk about pixels on these interaction design pages is about effective pixels, as reported in the browser (i.e. divided down from physical pixels for retina displays).

  1. the default column and divider proportions are giving for each view above;
  • users can adjust the column widths and divider proportions; this will not cause the views to scroll, and is persisted for the project; resizing the masters or instances column will affect both views they appear on;
  • when the browser viewport is resized, column and divider proportions are maintained;
  • all three rules above are subject to the following limits:
    • minimum width of a view (what is shown in the viewport) is 960px (i.e. if the viewport is narrower than that, the view scrolls horizontally);
    • the minimum width of the parameter, masters and instances columns is 180px;
    • the maximum width of the parameter, masters and instances columns is 270px;
    • the fonts column width is not user adjustable, it is 1/16th of the viewport width, capped by a maximum of 80px;
    • no further limits; user common sense prevails.

yes, horizontal dividers can be moved completely up/down, to the point where the panel above/below it is completely invisible.

where did the menus go?

Defining one’s own menu bar in a web application is problematic: hide the normal browser one? It is a sure way to create user panic. Have two menu bars? How unsatisfying.

For experienced interaction architects designing a web application is also an opportunity: one is working in a quasi-lawless grey-zone between web and desktop app and can simply do the right thing. Beyond competently picking the most befitting web and desktop metaphors, one can also create new hybrid forms that are excellent solutions for the design context.

So here we are. There is no HIG obligation to define a menu bar, thus we are not going to do it. Instead, we will place menus at the context they are operating on. In our layout we have panels that deal with—i.e. are home to—the project, parameters, masters, instances, design spaces, fonts & families, metadata, among other things. Each of these panels is labelled at the top with the type that they deal with.

These labels can be reused to attach a menu (see a above) that contains the actions that can be performed on this context; b shows the mouseover state: a menu button—the mouseover area is equal to the rectangle enclosing the button. Clicking anywhere in the button opens the menu. These menus better be native or equivalent, with support for all modes of popping up/down depending on space, keeping open and closing, invoking a menu item or bailing, and menu dividers. These menus will be referred to as local menus.

In this way we can provide a project menu (replacing the normal File one in desktop apps), parameters menu, masters menu, instances menu, design spaces menu, fonts & families menu, metadata menu, among other things.

What is missing is the all-important Edit menu of desktop apps, one that works on many different types of objects. Of interest to us are the standard functions Undo/Redo, Cut, Copy & Paste, Duplicate and Delete.

Undo/Redo, Cut, Copy & Paste we can handle via the standard browser Edit menu. This will provide users also with standard keyboard shortcuts. Duplicate is not present in browser Edit menus and we will provide it locally, usually via a button in the layout. Delete is present in browser Edit menus but maybe a bit fast to be used to delete Masters and Design spaces; I prefer to put Delete items in local menus for that.

what about right-click menus?

Right-click menus are a tertiary interaction method, one defines them after primary (buttons and menus) and secondary methods (direct-manipulation shortcuts) have been defined. Then one looks where one still needs a right-click menu.

working with projects

Always at the top of the viewport we find the project panel, which also includes the controls to switch the 3-view layout.

The strip itself looks like this (left and middle part shown only):

On the left we have the project label + name, with local menu attached. Centred on the project panel there is a set of three toggle buttons, which switch between the three main views.

When the project name is double-clicked on it becomes an editable text field, where the project name can be changed. The focus leaving the field ends and commits the name change. Undo applies to this action. The project name is used in the browser window title: "Metapolator: <project name>".

The local menu is as follows for file-based model:

  • New
  • Open…
  • Duplicate
  • -- <separator> --
  • Close
  • Save
  • Save As…

for an auto-persistence model (surely the way to go in the future):

  • New
  • Open…
  • Duplicate
  • -- <separator> --
  • Close
  • -- <separator> --
  • Delete…
  • -- <separator> --
  • Open File…
  • Save As File…

notes:

  • New opens a new, empty project into a new Metapolator instance in a new browser tab.
  • Duplicate copies the current project into a new Metapolator instance in a new browser tab, with a derived project name ("<project name> copy").
  • Open… opens into this browser tab only when a new, empty project is loaded, else into a new Metapolator instance in a new browser tab.
  • Close leaves the tab open, with no project loaded.
  • Delete… removes this project from the database, for ever…
  • Open File… and Save As File… interface to the file system instead of the database.

Whenever this instance/tab of metapolator is running without a project loaded, the project name and local menu are not shown; instead simple links to open a project or create a new one are shown:

(adjustment) master management

As mentioned before, the (adjustment) master column is the panel that ties together the Parameters and Design Spaces views. Vertically this column is divided in two (default: at 50%), with a master section at the top and a adjustment master section below it:

(yep, the divider between the two can be moved up/down by users.)

master section

The master section is completely occupied by the master list with a label + local menu above it:

quick overview: this project contains 7 masters; one (Light) is currently selected, any edits or actions are applied to it; two other masters (Thin, Thin Italic) are marked to be also viewed in the specimen (in the Parameters view); there are two master sequences, one containing 4 masters (called Weight) and one containing two—called Itals.

list behaviour

The list scrolls vertically when necessary and consist of 3 columns. From left (for L–to–R UI locales) we see:

  1. sequence column
  • view column
  • control column
view column

The view column shows some characters, set in this master, to identify it. Which characters appear there by default is dependent on the scripts setup of this master.

  • The characters can also be edited by users: double click to get a text edit box; this allows users to set up their own identification system;
  • when a master is not part of the current selection, clicking its view column toggles display of this master in the specimen (in the Parameters view); a highlight in this column confirms the view mode;
    • mouse-down in the view column, drag across multiple masters, release: switches the view mode of all masters involved on/off, depending on whether the mouse-down master went on or off;
    • the toggle is on mouse-down; when the mouse is down and moved outside the view column, the item is un-toggled (also for the swipe action above); when the mouse is released outside the view column, the view state of the item is un-changed(also for the swipe action above).
  • to be clear: when a master is selected, its view column cannot be toggled, also not by dragging the mouse across;
  • being (de)selected does not change the view mode of a master.
control column

The control column shows the name of the master and allow users to directly manipulate the master list item:

  • click to select; standard list multiple selection—i.e. add and subtract items through command/ctrl and shift keys—is fully supported; one or more masters can be selected in this list, this is what gets manipulated in the Parameters view (parameter editing, local menu actions) and the Design Spaces view; ah, and what is selected is always shown in the Parameters view specimen; note that two separate select states are to be maintained, one for the Parameters view, one for the Design Spaces view; while a transition is made from view to view, the select state is swapped out, preferably smoothly;
  • double click to rename master, to get a text edit box;
  • drag and drop to resort master list items (also of a multiple-selection);
  • drag and drop into a design space (also of a multiple-selection).
sequence column

Here master sequences are managed. All masters have a dot in this column—this identifies masters in other places in the UI. Connected dots show the extend of the sequence, and the arrow on the bottom item shows the top-down order of the sequence. The title item above the top master identifies the sequence elsewhere in the UI, double click to get a text edit box.

  • create master sequences via local menu (see below), or by mouse-down, drag across multiple masters, release: all masters involved form a new master sequence; default title: "sequence <number>", where the number steadily increases (for the project scope);
    • the sequencing starts on mouse-down; when the mouse is down and moved outside the sequence column, the sequencing is undone; when the mouse is released outside the view column, the sequencing did not take place.
  • drag and drop masters (via in the control column) to:
    • resort in the sequence;
    • add to sequence by dropping inside;
    • remove from sequence by dropping outside.
  • extend the sequence by grabbing the top/bottom dot and dragging it over masters above/below the sequence;
  • reduce the sequence by grabbing the top/bottom dot and dragging it over masters down/up towards centre of the sequence;
  • click in the sequence title item to select the complete sequence;

    this is different than selecting all the masters in a sequence (e.g. in how it interacts with adding and removing items, or with copying it and pasting it elsewhere); multiple selection also works here;
  • drag and drop complete sequences, via the title item
  • a sequence contains two or more masters; reducing a sequence to one master by any means results in removing the sequence;
  • ps: masters and sequences can appear in any order on this list (as long as sequences are continuous, i.e. only sequence members are shown in a sequence).

clones

Clones are very useful for making the same master part of several master sequences, without creating the maintenance burden that copying would cause. Clones are indicated by the clone symbol in front of there name:

Clones work like hard links on the unix file system: all clones are one and the same thing; there is no target and link relationship. all the data of related clones, even the name, is, well, one and the same thing. rule: when there are exactly two related clones, and one of them gets deleted, then the last one left stops being a clone and is a normal master, again. And just in case you wondered, clones can be cloned to simply increase the number of related clones.

buttons

At the bottom of the list action buttons are displayed. From left (for L–to–R UI locales) we see:

  1. Import ufo button; imports a ufo and creates a new master out of it;
  • Duplicate button; duplicate the current selection of master(s) or sequence(s);
  • Clone button; clone the current selection of master(s) or sequence(s).

local menu

The local menu is as follows:

  • Import ufo…
  • Copy From Project…
  • -- <separator> --
  • Duplicate
  • Clone
  • -- <separator> --
  • Delete…
  • -- <separator> --
  • Set Scripts…
  • -- <separator> --
  • Quick Export…
  • -- <separator> --
  • Create Sequence
  • Delete Sequence…

notes:

  • these menu commands operate on single and multiple selections of masters and master sequences;
  • Import ufo… imports a ufo and creates a new master out of it;
  • Copy From Project… shows a project browser and then a master browser within a selected project; then copies selected master(s) to this project;
  • Delete… of master(s); deleting a master is a heavy thing: show a confirmation dialog (see below);
  • Set Scripts… shows a dialog to manage which scripts are supported by master(s);
  • Quick Export… of master(s) or sequence(s) to ufo, using best guesses where it comes to the trimmings (e.g. metadata, kerning, and opentype features);
  • Create Sequence out of a multi-selection of masters that are all not part of a sequence; when it is a discontinuous selection, this pulls them together under the top master;
  • Delete Sequence… Deletes selected sequence(s), but not the masters they contain.

dialogs

  • when: deleting 1 master, not in use on any design space; text: “Delete master?”; Buttons: OK, Cancel;
  • when: deleting 1 master, used on one design space; text: “Delete master? It is in use on design space <DS name> and will no longer be part of its instances after deleting.”; Buttons: OK, Cancel;
  • when: deleting 1 master, used on several design spaces; text: “Delete master? It is in use on <# of DS> design spaces and will no longer be part of their instances after deleting.”; Buttons: OK, Cancel;
  • when: deleting several masters, not in use on any design space; text: “Delete <# of masters> masters?”; Buttons: OK, Cancel;
  • when: deleting several masters, used on one design space; text: “Delete <# of masters> masters? They are in use on design space <DS name> and will no longer be part of its instances after deleting.”; Buttons: OK, Cancel;
  • when: deleting several masters, used on several design spaces; text: “Delete <# of masters> master? They are in use on <# of DS> design spaces and will no longer be part of their instances after deleting.”; Buttons: OK, Cancel.

undo, copy + paste

All editing of master (sequence) data, naming and configuration (e.g. sorting) is Undoable.

Ah, and of course the current selection of master(s) or sequence(s) can be cut, copied and pasted—

  • within the same project;
  • between projects, in different browser tabs and even between different browser app instances (e.g. a firefox and a chrome) on the same desktop.

adjustment master section

Whereas masters are complete definitions of a font (to the extend of the supported glyph range), adjustment masters start empty and contain only targeted, well, adjustments.

A typical example of an adjustment master is:

  1. empty, apart from—
  • for the whole master, scale parameter X by 0.98;
  • for a few glyphs, scale parameter X by 1.01 and offset parameter Y by +3;
  • for one glyph, scale a pen parameter for 2 points;
  • for another glyph, move one point a few mEm.

The adjustment master section is completely identical to the master section, apart from the following changes:

The label above the list shall be "Adjustment Masters".

sequence column

Different symbols are used in the sequence column: up-pointing triangles, derived from the delta (Δ) symbol, and the bottom item is identified by an end-of-the-line symbol.

clones

Adjustment master clones are like master clones where it comes to their (few shreds of) parameter data. However, several related clones can be placed in the same design space (to build structures of the same adjustment) or they can be placed on several design spaces.

note: because related clones are placed in different locations or design spaces, each of them will display differently in the specimen, because ~99% of what they look like is determined by the underlying metapolation of their location.

buttons

Action buttons are different:

  • New button; create an empty adjustment master;
  • Duplicate button;
  • Clone button.

local menu

The local menu is a bit different:

  • New
  • -- <separator> --
  • Duplicate
  • Clone
  • -- <separator> --
  • Delete…
  • -- <separator> --
  • Set Scripts…
  • -- <separator> --
  • Quick Export…
  • -- <separator> --
  • Create Sequence
  • Delete Sequence…

note that a adjustment master can only be displayed as a specimen when it is placed on one (and only one) design space, in that state is can also be quickly exported.

and that is it…

(family of) instances management

As mentioned before, the (family of) instances column is the panel that ties together the Design Spaces and Fonts views. Instances are much more lightweight than masters; they are incidental harvesters in the design space, instead of its cornerstones. It is our goal that instances are also used for experimentation, on a whim, quickly making a couple of them, to toss away when they are surplus to the design activity. This means that although the interaction of the instances list has a lot in common with the master list, its design must be tuned differently to be fit for use. The description below is in absolute terms and not a delta to the masters section.

The instances panel is completely occupied by the instances list with a label + local menu above it:

quick overview: this design space contains one instance and one family of instances; the lone instance (Instance #1) is probably for exploration, because it has still its default name; the family of instances is called Exotic and consist of 9 instances; one (Thin) is currently selected, any edits or actions are applied to it; two other instances (Light, Regular) are marked to be also viewed in the specimen (in Design Spaces view).

list behaviour

The list scrolls vertically when necessary and consist of 3 columns. From left (for L–to–R UI locales) we see:

  1. family column
  • view column
  • control column
view column

The view column shows some characters, set in this instance, to identify it. Which characters appear there by default is dependent on the scripts setup of this instance.

  • The characters can also be edited by users: double click to get a text edit box; this allows users to set up their own identification system;
  • when an instance is not part of the current selection, clicking its view column toggles display of this instance in the specimen (in Design Spaces view); a highlight in this column confirms the view mode;
    • mouse-down in the view column, drag across multiple instances, release: switches the view mode of all instances involved on/off, depending on whether the mouse-down instance went on or off.
    • the toggle is on mouse-down; when the mouse is down and moved outside the view column, the item is un-toggled (also for the swipe action above); when the mouse is released outside the view column, the view state of the item is un-changed(also for the swipe action above).
  • being (de)selected does not change the view mode of an instance.
control column

The control column shows the name of the instance and allow users to directly manipulate the instance list item:

  • click to select; standard list multiple selection—i.e. add and subtract items through command/ctrl and shift keys—is fully supported; one or more instances can be selected in this list, this is what gets manipulated in the Design Spaces and Fonts view; what is selected is always shown in the specimen (in Design Spaces view); note that two separate select states are to be maintained, one for the Design Spaces view, one for the Fonts view; while a transition is made from view to view, the select state is swapped out, preferably smoothly;
  • double click to rename instance, to get a text edit box;
  • drag and drop to resort instance list items (also of a multiple-selection);
  • drag and drop into a design space (also a multiple-selection).
family column

Here families of instances are managed. All instances have a diamond in this column—this identifies instances in other places in the UI. Connected diamonds show the extend of the family, and the arrow on the bottom item shows the top-down order of the instances. The title item above the top instance identifies the family elsewhere in the UI (e.g. for font name generating), double click to get a text edit box. The title item also shows the number of instances contained, double click to get a text edit box with up/down arrows:

The changes to the number of instances is applied at the bottom of the list.

  • create families of instances via local menu (see below), or by mouse-down, drag across multiple instances, release: all instances involved form a new family of instances; default title: "family <number>", where the number steadily increases (for the project scope);
    • the family gathering starts on mouse-down; when the mouse is down and moved outside the family column, the family gathering is undone; when the mouse is released outside the view column, the family gathering did not take place.
  • drag and drop instances (via in the control column) to:
    • resort in the family;
    • add to family by dropping inside;
    • remove from family by dropping outside.
  • extend the family by grabbing the top/bottom diamond and dragging it over instances above/below the family;
  • reduce the family by grabbing the top/bottom diamond and dragging it over instances down/up towards centre of the family;
  • click in the family title item to select the complete family;

    this is different than selecting all the instances in a family (e.g. in how it interacts with adding and removing items, or with copying it and pasting it elsewhere); multiple selection also works here;
  • drag and drop complete families, via the title item
  • a family contains two or more instances; reducing a family to one instance by any means results in removing the family;
  • ps: instances and families can appear in any order on this list (as long as families are continuous, i.e. only family members are shown in a family).

buttons

At the bottom of the list action buttons are displayed. From left (for L–to–R UI locales) we see:

  1. New instance button; See local menu item of the same name;
  • Create family of instances button; See local menu item of the same name;
  • Duplicate button; duplicate the current selection of instance(s) or family/-ies;
  • Delete button; See local menu item of the same name.

local menu

The local menu is as follows:

  • New
  • Duplicate
  • Delete
  • -- <separator> --
  • Promote To Master
  • -- <separator> --
  • Quick Export…
  • -- <separator> --
  • Create Family
  • Delete Family…

notes:

  • these menu commands operate on single and multiple selections of instances and families of instances;
  • New instance, set to default metapolation mix; when this instance is created inside a family, the metapolation is a 50-50 mix of instances above and below; on the edge of a family, extrapolate;
  • Delete of instance(s); deleting an instance is lightweight—no dialog shown; but deleting the last instance of a design space is the same as closing this design space; thus we can handle it the same: (raise the design space when necessary) cover it in contrasting color and put a confirmation dialog;
  • Promote To Master of instance(s)—transformed to master(s)—or family/-ies—transformed to master sequences; the instance(s) or family/-ies involved remain untouched;
  • Quick Export… of instance(s) or family/-ies to ufo, using best guesses where it comes to the trimmings (e.g. metadata, kerning, and opentype features);
  • Create Family out of a multi-selection of instances that are all not part of a family; when it is a discontinuous selection, this pulls them together under the top instance; when there is no aforementioned multi-select, create a new family of 9 instances;
  • Delete Family… Deletes selected family/-ies, but not the instances they contain.

dialogs

when: deleting the last instance on a design space; text: “Delete instance? This also deletes the design space <DS name>.”; Buttons: OK, Cancel.

undo, copy + paste

All editing of instance (family) data, naming and configuration (e.g. sorting) is Undoable.

Ah, and of course the current selection of instance(s) or family/-ies can be cut, copied and pasted within the same project.

working with masters and glyphs in context

Let us develop the section called ‘character range or specimens’, the one visible in the Parameters department. It has got a range of important jobs to do:

  1. show the character range or specimen for any number of masters and adjustment masters—the ones that are highlighted in the masters and adjustment masters panel;
  • let users control how much, how big and how mixed it is what they see;
  • let users control if they are working with parameters & skeletons on a master, glyph, or sub-glyph level—on one or more items;
  • offer, where appropriate, direct-manipulation of skeletons and parameters;
  • show the immediate effect (live update) of parameters & skeleton changes;
  • let users add, sort and delete glyphs from masters.

1. character range is a specimen

The first thing we will do is to put the character range view and specimens on equal footing—well almost, see later. That means: the character range view is just another specimen, where glyphs appear only once, by default sorted according to character code.

Thus character range appears on a popup list of possible views, as does a general sentences view (sourced from a news feed, one for each script) and some specific ones for checking numbers, punctuation, etc. This list is extendible through html files.

2. character filtering and the big mix

These interactions are for the character range view:

  • when multiple (adjustment) masters are to be shown, mix masters per glyph, or pivot per master;
  • a long display size slider, offering a wide range of sizes.

These interactions are for the general sentences view:

  • a text field allows to enter characters which users want to focus on; a slider sets how strict this focus is: from ‘at least one entered char must appear in words’ to be shown, to ‘only combinations of the entered letters’ are shown.
  • when multiple (adjustment) masters are to be shown, mix masters by: the paragraph / word / character;
  • when multiple scripts are to be shown, mix scripts by: the paragraph / word / character;
  • a long display size slider, offering a wide range of sizes.

These are for the other views:

  • ability to mix multiple (adjustment) masters;
  • ability to mix multiple scripts;
  • a long display size slider, offering a wide range of sizes.

3. the highlight

What is highlighted (aka selected) in this section steers the level work is done:

  • if nothing is highlighted, the work is done on the (adjustment) master(s) that are highlighted in the masters and adjustment masters panel;
  • if one or more glyphs in the current view are highlighted, the work is done on these glyphs;
    • although all specimens (including character range) are very typographical (for lack of a better word), i.e. well-set text, the highlighting behaviour is that of a grid of glyphs (completely analogue to making (complex) selections in an icon grid in a file browser, including the use of rubber-banding to make selections, and shift and cmd/ctrl to grow and shrink these).
    • how to highlight? it is very important that the ‘black’-on-white view of these glyphs being worked on is preserved, but also that it is clear that they are the ones being worked on; even the visual interaction with their nearest neighbours should not be interrupted. A coloured rule under the glyph seems to be the most promising.
    • note that multiple glyphs can be highlighted across multiple (adjustment) masters (since these can be displayed at the same time).
  • if one or more sub-glyph points are highlighted, the work is done on these points. note that multiple points can be highlighted across multiple glyphs, across multiple (adjustment) masters (since these can be displayed at the same time).
  • if one or more sub-glyph lines are highlighted, the work is done on these lines. note that multiple lines can be highlighted across multiple glyphs, across multiple (adjustment) masters (since these can be displayed at the same time).
  • if one or more sub-glyph vector shapes are highlighted, the work is done on these vector shapes. note that multiple vector shapes can be highlighted across multiple glyphs, across multiple (adjustment) masters (since these can be displayed at the same time).

example: with the components we got up to now it is very easy to set up a view that is filtered to show only the glyphs ‘a’ and ‘g’, for 3 master fonts (i.e. 6 glyphs are on the screen). Now the 3 ‘a’s can be multi-selected and a parameter change at glyph level can be done. Next, for all 6 glyphs one point is selected (6 points in total multi-selected) and the point parameter tension-in is lowered a bit (to 90% of its previous value). Finally, nothing is highlighted and for the 3 masters a parameter change is made at master level.

4. down to the bone

From a certain display size (say, 144pt) and up, it becomes feasible to directly manipulate (i.e. edit using the mouse) the skeletons. These can then be shown for a glyph on mouse-over. Approaching points or lines enlarges them to be able to grab them faster, shaving fractions of a second of the time for each action.

however, paradoxically some restraint has to be practiced when planning for what parameters (this is what it essentially is) direct manipulation is to be provided. This is for the following reasons:

  • implementation effort for v1.0;
  • we have to wean users off their old habits of working glyph-by-glyph, and of getting results directly pushing around the outline (i.e. the edge) of a glyph shape; we have to put the brakes on what facilitates this.

Our guiding credo should be: we provide direct manipulation there, where it would be completely silly not to.

5. it’s alive

Immediate, live update of parameters & skeleton changes means in practice within 500ms. The bad news is that every instance of what is being worked on must update simultaneously; the good news is that only what is visible needs to update.

6. managing

Ah yeah, what is special about the character range view? It is the only one where it makes sense to offer glyph management (add, sort and delete).

parameter review and editing

Superseded by a dedicated page and an interim design.

metapolation sliders

Superseded by this.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.