I met with Alberto Ruiz at the recent GNOME Summit in Boston, and we talked a bit about making some improvements to the GTK font chooser dialog. He had a cool prototype he shared with me and wanted to try to iterate to a good design trying a usability-based approach. (Yay! 🙂 ) I promised him some work by the end of this week, so here it is. 🙂
Here’s the current GTK font selector UI:
Here’s the prototype Alberto coded up:
I started off by conducting a heuristic evaluation of both the current GTK font selector UI and Alberto’s prototype. The full heuristic evaluation is available on the GNOME wiki. What is a heuristic evaluation? It’s basically an usability expert walkthrough of an interface to compare it to a general set of heuristics, which are basically just best practices for interfaces. Honestly, it’s really just a fancy word for sanity-checking. 🙂
Next, I played around with some mockups that addressed some of the issues identified in the evaluation. I also added some ideas that Alberto and I had while discussing the project. Here’s one of the mockups; click it to see the full set:
There’s at least a couple issues still outstanding that the mockups don’t really address so well:
- The fonts are all presented in a flat list. I have several hundred if not over a thousand or so fonts installed on my machine. There are fonts of all different styles, character sets, intended usages, etc. It’s a lot to sift through. It’d be nice to see fonts by category or type instead. I have a really rough dumb mockup at the very bottom of the page as a first attempt to think of a way to address this, but, it’s terrible and has tons of problems. 🙂
- A lot of times multiple fonts in the font chooser show up exactly the same for me. It gets confusing because then I don’t know what the ‘true’ name of the font is that I’m seeing in the preview. While it isn’t mocked up, one idea I had for this is that a little foot note: “This font is an alias of foofont” could appear in small type below the preview text box.
- To the point the text previews aren’t relevant to real-world type usage – we also had an idea for auto-generated phrases that, if you couldn’t think of what to type in the preview, it would fill in for you. Maybe phrases that would show off common character combinations. Not sure. I didn’t mock that up, though.
Anyway, probably the next step is for me and Alberto to haggle over the feasibility of this first cut at mocking things up and come up with a design he could then implement as a testable prototype. One thing we talked about at the summit is that he could write a toy text editor that uses the new font chooser prototype. Then, I could run some usability tests on it. I had a cool idea for the usability test – I could hand the users a poster design that used a few different fonts in different sizes and ask the users to reproduce the poster to their best ability. Based on the test, we could discover any lingering issues with the design and hopefully iterate to make it better.
These mockups aren’t pixel-perfect of course; they’re exploratory to try to convey some new ideas. (for example, I know the slider tickmarks are ugly right now.) What do you think?
In filtering down fonts.. is there information like the old X bitmap fonts? say something like sans, serif, right-to-left, left-to-right, country code, style? This could allow for a quick pass of fonts. After that I think it would require a customize filter/folder system so that one could put a set of "I likes", "I hates", "Good for X sites" etc.
Usability question.. I see you have AA BB CC in your mockup. From your last font posting you mentioned that the font was good about seperating 0 from O and 1 from l. Would it be worthwhile to have those in the listing or would that make it more confusing?
I think there is metadata we can use. It seems like a good filtering system is an important next step for these mocks. 🙂
On the font preview text, I'm not sure what would be appropriate. Albert mentioned that pango offers character set-specific preview text, and I don't know what's in the preview text. I think maybe getting preview text that shows *something* for every font no matter what character set it uses is probably a top priority. Knowing that the numbers aren't confusing-looking is important, though. But maybe it could be left for the user to type them into the preview if they're concerned about that…. I'm not sure though.
I really like the style selector and I like the fact you'd still be able to specifically enter in the font size instead of a slider only.
One of the things my Mom was looking for was a way to either have favorite fonts or to hide fonts she didn't use. I suspect something like a "most used" or "bookmarked" filter might be useful for people with large numbers of fonts installed.
I'm not quite sure how to incorporate such a thing into the interface without making it too busy. Any ideas?
Hi Russll, I *love* the most-used / bookmark idea. I want that!
I'll play around and see how it could be integrated!
I would definitively use a favourites option if available.
It's a good idea, so many fonts in the list make it hard to choose the one we want.
I love where this is heading.
The way I'd imagine the font search being of most use to me would be if it searched on all available fields by default (name, type, style, etc.) but also allowed more advanced queries, searching for specific properties including derived/guessed ones.
For example, if I am searching for a monospaced font starting with "courier", I would like to be able to type a query like:
name:"courier*" width:fixed
Perhaps unjustifiably complex?
I don't think it's too complex – I think it's an advanced feature, but one that wouldn't affect new users too much – it's something users could grow into over time. I do worry about the discoverability, but maybe Alberto and I can mull it over and see what we come up with. Thanks!
I like the mockups, mostly what Alberto did. I suggest to add some plus features:
– one button with adding/removing fonts.
– connecting possibility to the repositories to install further free fonts
– with logos the font type before the name makes very easily manageable is it scalable, or not
– small copyright box with the true filename, alias, one line description about the vendor
Thx,
best wishes.
Z
Hi Zoltan, I think adding/removing fonts should be reserved for a system-wide centric font capplet – this is meant to be the dialog that pops up while you're say in Gedit or Gimp or something changing a font. So the user is really primarily in the mode of choosing from fonts, consuming them, not modifying them. I do think we need a good way to add/remove fonts though. It was removed from the appearance capplet a while back to my dismay!
I like your idea of the copyright box, because one very big concern for me is the license of a font before I use it. I'm not sure how wide a concern that is though, which is why I left it out of the mockups. Perhaps we can revisit it…
I don't think the copyright info is that important: by default you have installed only Free fonts and have to manually add the proprietary ones, so I suppose you know what you are doing. The huge majority of the users will have only Free fonts, for them this would be unnecessary bloat.
Máirín, popups are a terrible UI. Sure the core doing font installation should be kept PK-side but there's no reason the chrome should not be nicely integrated.
When a user is in the fonts chooser he wants to know what's available. And fonts in packages not installed yet (but listed in the configured repos) are definitely available, just a little farther than local fonts. It's a gradient of availability
An add/remove that browsed for random fonts on the filesystem would be something else entirely, and probably a terrible idea.
Licensing is a very big concern in apps that embed fonts in documents, since a lot of font licenses explicitely forbid this (or present other problems such as the GPL without font embedding exception)
Also making the licensing explicit is a good way to promote libre fonts, since many non-libre fonts have restrictions users unknowingly infringe.
When selecting from a large set, one of the best paradigms is
a "narrowing" interface, when a refinement of the selection leads
to filtering out of non-matching items.
A concrete example may be the search bar in kaddressbook or
kmail. Typing characters into it, incrementally filter the list so only
addresses/messages containing the sub-string remains.
For fonts we usually want to filter by their attributes (size, bold,
mono, etc.) and not by strings. A very old example for this is
xfontsel:
* What's bad in this example and should be ignored:
– The UI is horrible (80's style Athena widgets)
– Used legacy-long-font-names-that-encodes-their-properties
– Only shows the a single font matching the criteria.
* What's good and should be taken for a new design:
– Each attribute has a UI filter – any value (*) or specific values.
– Limiting a specific attribute narrows the list (there's a number
shows the current matches). In a modern design we should show
not only the first match (as xfontsel), but a narrowed down list
of matches.
There's still an important challenge with all modern designs —
Language coverage is not shown or be used as a filter.
I'm not sure if this information can be easily extracted from
modern fonts. Also a UI for this should be non-obstructing for
the most common case (latin).
These are great points, and thank you for pointing out xfontsel – we'll take a look!
However when you have as many attributes as modern fonts have, you can not multiply the dropdowns like in xfontsel without producing a usability nightmare
xfontsel was written in a much simpler world. And it already had horrible UI for the simple fonts that existed at the time
Two thoughts:
1. I am not sure about the use of the slider as an input mechanism for the Font Size. In theory, i can enter in a font size above 96pts, does the slider just stop at the far right hand side in those cases? (i know fonts at that size are edge cases)
2. The mockups essentially have 2 "Previews" of the font: the large "Preview:" area, (i love the way the user can interact with that little widget, BTW.) and the rreviews in font list itself (depeicted in the mockups as "Aa Bb Cc Dd .." ). Would there be any benefit to have the preview(s) in the Font List itself use the (user changeable) test that is also used in the main Preview Area?
mo and Alberto: awesome work, and so glad the dialog is being upgraded 🙂
cheers,
ryanlerch
Just had another quick thought / question:
How useful will the preview window be with larger font sizes?
cheers,
ryanlerch
Hey Ryan, my idea with that is that it's kind of like a magnifying glass on the font, so you can get a feel for it's "look" or "character" but at the same time be able to view it at a more reasonable size. I was thinking it would always stay the same size, so even if you up the font to a ridiculous size, it would be at a sensible size and you could still see the font.
I'm not sure if it's too hokey, weird, or useless. It is definitely something I'm hoping isn't too much of a PITA for Alberto to prototype, because I'm really eager to test it out with the usability lab. 🙂
I think I prefer the preview window to show the text at the same size as the document, so i effectively get what i see.
Almost every glyoh will look good at big sizes. What's tricky (especially for screen rendering) is small sizes and how glyphs are positioned next to one another
Therefore I believe a font waterfall (same text at increasingly bigger sizes) is more useful than a sample at big size. You can always emphasize the size the user selected by putting a pointer next to it in the waterfall (or centering the preview on this line)
Hey Ryan! My idea with sizes above the bounds of the slider (or sizes that don't have sticky points on it even) is that you'd manually type them in the spin box to the right of the slider. Do you think that would work for you, or would it be too annoying? I thought since it is an edge case maybe it's not so bad to do it that way.
I like the idea of having the large preview affect the smaller previews in the list widget of fonts. I think Alberto might be able to do that, we'll talk and see if it's possible!
Once we get this right, we definitely need to upgrade the one in Inkscape too. I *hate* how it always forgets the information about my font on canvas so I always have to reset bold / italic / whatnot when I go in just to change the font size.
A good compact UI for size selection would be a dropdown with usual sizes that let you type a specific non-usual size if you wanted
Also the size should have a unit. Depending on the app, you'll want vector units (pts), percentages, actual pixels, etc (I know gtk is currently braindamaged in that it does not make the unit explicit, so different people disagree on what a gtk font size means)
In the mockup you are proposing as the chosen one… why are you using push buttons (I guess they are toggle buttons) to select bold/italic, when a checkbox for each could make more sense?
Hey! None of these are chosen yet – they are all just ideas (well except the first screenshot which is the current dialog.)
The screenshot you're talking about is of Alberto's prototype. The push buttons were an issue he identified with the prototype, so you'll see in the newer mockups (further down the page) we replaced them with a dropdown.
Just one comment: the size chooser is too important to be a slider. The user needs precision when it comes to font sizes, and a slider is better for more coarse choices. For example, making sure that a document is in 11pt type (rather than 10pt or 12pt) is a real-world need and it would be infuriating to have to fumble around an imprecise drag&drop-type widget to do so.
Hey zzz, you know you're right! Hmmm. What I tried to do with the slider is have 'sticky points' for all the sizes between 6-14 but the very mechanics of a slider still might make it frustrating. We can try to see how bad the effect is in usability testing. Maybe there's a way to have a slider for a rough change of the font size, and another control for more precise sizing? (Would working with both the slider and spin box be annoying do you think?)
The main problem is that the proposed dialogs some common interactions more complex:
1) Font-Size selection goes from 1 click to drag-and-drop
2) Font-Style selection goes from 1 click to 2 clicks (click to open combobox, click to choose)
A better approach would be to get the current gtk font dialog and add:
1) A Category chooser, to shorten the amount of scrolling required for Font-Family selection. This should be placed to the left of the Font-Family chooser, like the "Collections" box here: http://www.unifont.org/fontdialog/images/TexEditP…
2) Searching, just like in the mockups you posted
3) Inline preview, like in the mockups you posted
It doesn't seem to me that the interaction for font-size selection needs any change. Maybe a mixed approach with a slider+selectionbox (like in the screeshot I posted above) would work ok.
Yessssssssssssssssssssssssss ! Please change the font selector. The current one is a nightmare. Your proposal is way better. Great job !
Alongside the idea of grouping the fonts by type, style, etc…, that would be great to group them by alphabet. I mean I have a lot of non-latin fonts and they are useless when I look for a latin alphabet (and the reverse is true as well, even not talking about the fonts having only symbols).
That would be very helpful to think about 2 uses cases:
– word processing of any type
– gfx and artistic creation.
I don't choose my fonts the same when I use inkscape (like I do for SVG-cards for example) and abiword.
It means we need some preprocessing of the fonts to classify them, I guess.
Oh my goodness, that is a great point. Whether or not you're in abiword or Inkscape does make a big difference doesn't it? Maybe we show different filtering options depending on which app you're coming from (or at least give the app an API to call up / hide different options.) Thanks for pointing this out!
Gorgeous work, hope to see this in Ubuntu soon!
It would be useful if fonts had some metadata (tags) so you can filter by some keywords: cursive, serif, symbols etc.
Yep, it seems that's a big request we'll have to tackle in these mockups! 🙂
[…] mockups for gtk font chooser http://mairin.wordpress.com/2009/10/15/gtk-font-selector-ui-update-round-1/ […]
There are many font families installed by default that only serve to cover a single writing system, like indic, arabic, CJK, etc.
It doesn’t make much sense to preview these fonts using latin sample glyphs. Unfortunately it is not obvious from the name what script these families are meant to be used for. And a given user would likely only want to (or be able to) /write/ in a very small subset of these even if she appreciates that her system is able to /display/ a large coverage of Unicode.
There should be a way to subcategorize the font list by what range of writing systems the families are meant for. This is not necessarily congruent with what Unicode ranges are present in the fonts. All of them have (sometimes shoddy) latin in them, for instance.
Defoma (Debian Font Manager) adds useful category fields to the font packaging (Location = Korean, Location = English Thai, Location = Japanese, etc). I don’t know if something like it is available to all distros. Perhaps fontconfig can provide that info, too.
Also, good that you added the full list of styles back. Bold and Italic are just not enough nowadays.
Great point! It looks like we need to consider character set when we figure out the filtering system.
Modern fonts usually support many writing systems. Therefore trying to represent fonts in a script ⇒ font tree will only result in many duplicated entries (that will annoy users). Gucharmap is a good exemple why a simple script list is not a user-friendly UI
About the mockup:
I don’t think a slider for the size makes sense. Why bound it? 96pt is not all that large. What if you want 500pt (or 2000pt, …)? What if you want fractional sizes? There’s no way to tell in advance when the font is used on a scalable canvas. Use case: drawing a map to scale with 1pt == 1m.
Sooner or later Pango, or HarfBuzz, will support advanced font features of Opentype fonts. Perhaps the dialog should anticipate that and be designed with extensibility in mind.
The zoom thing seems complicated.
Well the idea with the slider (which could totally off) is that it bounds you to the most common point sizes, and if you want to go beyond that, you use the spin box next to the slider. Does that make sense? I think maybe it's a little too complicated since it seems a few folks in these comments missed it.
For the 1pt == 1m case, would allowing the user to type 1m in the spin box and greying out the slider be a reasonable solution?
I'm not familiar with advanced open type features (although i don't think all the fonts in my system are open type.)
The scale example was merely meant to illustrate that sometimes extreme point sizes might be necessary. In this case the canvas (e.g., in Inkscape) might be 20000pt just for scale reasons.
On OpenType features, DejaVu Serif for one has the ligatures feature enabled by default. This is why in Firefox you will see ff, ffi, ffl, fj as ligatures. But it has also the discretionary ligatures feature, which have to be enabled explicitly by the user.
And I guess sonner or later HarfBuzz will expose these.
This is how Adobe shows these options, and there are more: http://www.adobe.com/designcenter/incopy/articles…
Can we filter fonts by language? font-config knows what font supports what language. If I write a Vietnamese document, I would not bother checking out a Russian font for example.
Yeh, I think we need to – it's a good point! 🙂
Only please do not use the system locale as filtering criterium. People write documents in other language than their UI all the time
The correct filtering argument is script, not locale (since there are regions where several writing systems cohabit in the same place, and a writing system can be share by several regions)
http://unicode.org/iso15924/iso15924-codes.html
Though you need to also take locale into account since (for example) balkanic cyrillic and russian cyrillic differ lightly
Your aim should be to find a simple and reduced paradigm for selecting from a long list of items filtered on 2 parameters while showing a preview.
Keep close to this and be very careful not to introduce more elements to this mix which do not really support/empower this paradigm. Think about what interface elements can add up to solve this paradigm elegantly. Look at other platforms/interfaces that deal with long lists.
Here some inspiration (perhaps there is something to learn from these): http://www.guidebookgallery.org/screenshots/font http://eyegene.ophthy.med.umich.edu/unicode/fontd… (The Apple one got search, font grouping and more)
Ah, and thanks for working on this!
Thanks 🙂 These are great pointers.
Filtering is absolutely critical. I've got a whole load of fonts on my system which show up the same in any sort of preview because they don't actually carry any Latin characters. I'd like to keep them around, because when I do encounter, say, Arabic text, I want it to render and not be a load of missing glyph symbols. But since I don't actually speak Arabic, I don't want to see them when choosing a font for rendering English or German.
So filtering by character sets or language or something along those lines would be amazing, if it was possible to do so (I'm not sure what metadata about coverage fonts actually have). Style filters would be good as well, but I'm less fussy about those at the moment.
Cool, we'll definitely try to tackle filtering next. 🙂 It seems the most requested feature here!
An issue I don't think you have covered is previewing of fonts meant for non-latin scripts. Using english text as preview text for these does not make sense, sometimes they do not even contain english glyphs and then a fallback font is used. For example, using some kind of category or language tag could solve this.
Also, as a native speaker of Swedish, you often find yourself wondering "does this font support åäö?". It could be useful if the preview of a latin font adapts itself to the system locale, if the font supports the required unicode code points, to show that it supports the characters required for the user's language.
Alberto mentioned that pango has some character-set or maybe locale specific font preview texts…. I really hoping it can help with your example of “does this font support åäö?” We'll have to poke at it and see. I agree this is a really, really important case.
But the workaround is to type your own text, with whatever special characters you want, in the preview area.
Yes. Swedes are not the only nationality that would have this problem, as you probably understood all latin-based languages which uses extra non-english characters would have it, and also other non-latin based languages have it – I know for example that Assamese has an almost identical alphabet to Bengali, except that it has a few extra characters, and most fonts thus handle both.
As Nicu pointed out below, a workaround would be to type your own text – however, this becomes slightly difficult if fallback fonts are used, in that case you would need to notice that a specific character doesn't fit in correctly, or that for example an 'å' is too different from an 'a'.
But yes, if fallback fonts are not used, it would be a somewhat viable workaround, although the better and userfriendlier solution would be to have a smarter preview text.
Tagging of fonts would be so cool!
Four cheers!
Would be a nice power feature to be able to click on the number above the slider and enter in a value… making it look like a normal field might make things look cluttered though
Well the intent was that you could enter a value into the spin box to the right of the slider. It seems like a lot of commenters didn't notice it though. 🙁
That because the slider in your mockup has an unusual size and shape so it distracts the attention? (also many people didn't notice the "Aa Bb Cc" text is only a placeholder)
I like your mockup!
I agree that we need additional filters like in xfontsel (but not as detailed and nicer). Additional information could be presented in a tooltip when mouse is over the font name.
Using a filter like in the last image of the mockup page would be interesting.
About font aliases, this could even be in the filter, that way we end up with only real fonts.
Great idea!
I don't think adding/removing fonts belongs in applications font selection dialogue boxes. Most users don't care about copyright of the fonts (Sad but true),
I'd like the search box to hide/fade out when the entire list of fonts is shown. I usually like to keep the fonts installed to a minimal. If i want to search i can click and start typing the name of the font (much like a good list view should).
Some questions about functionality, probably most of this being application (rather than toolkit designers choice).
Can the preview text could default to show the selected/highlighted font that it is going to applied to.
Also, if possible as part of the API, a callback to instant apply. On selection of a font, i would like to see the background/application redraw with the changes behind it immediately, even before hitting OK. Hitting the cancel or the X button should revert behavior. This may be too taxing for some systems to handle properly, but would be a nice option to have.
I agree with your instant apply idea. I'm not sure it's possible but I would really like to see that behavior.
"Can the preview text could default to show the selected/highlighted font that it is going to applied to."
That's a good idea in well. This happens in Inkscape's font chooser today, but it tends to strip attributes when you use it – e.g. if I'm using font foobar bold and size 24, when I select it and open up the font chooser, it defaults to like size 12 and strips the bold. Bad!
Great!!! I believe that it is more useful a standard text in preview box that would be changed each time when cursor heat a different font. Thank you anyway!!!!!
Regarding the real world scenario of users with hundreds or thousands of fonts, you should definitely give a stop at Fontmatrix (www.fontmatrix.net), and see how their ideas overlap with your design thoughts.
As 'Fontmatrix genesis' describes, the Fontmatrix project was started due to the lack of decent font selection widgets in Linux UI toolkits: "In the long run, I think of Fontmatrix as a pure font manager – for tagging and activating fonts – will vanish once someone writes the perfect font selection widget and makes it available for DTP applications.".
As you admit, the current widget just doesn't scale for users with more than a dozen of fonts. That's okay for rarely used tasks like configuration of an application, but it's a FAIL for any task where you have to choose fonts during regular workflow, like DTP or other kind of design works.
Fontmatrix has some nice ideas on all ends. I think there's plenty room for innovation here, implementing the best of them in a selection widget.
Cool, we'll take a look, thanks for the pointer!
I think you should go with your original mock-up but keep the font-preview as is now. The separate buttons for bold and italic sound nice but they contribute to a busy look that I'm not sure brings a whole lot to the table.
It still doesn't solve the real problem that people need some way to see "Hand-writing Frilly Fonts" or "Non-System Fonts" or "Monotype Fonts"…
–Rob
1. The main problem a modern font dialog needs to serve is filtering. We're increasingly moving to a world where large sets of fonts are installed by default (to render external documents that may require various encodings and styles), so raw font lists will be *long*, and overwhelm users if the font dialog is not smart enough. Criteria for filtering are font formats, available faces, available encodings, etc. Note that the filtering choices will be different for fonts used in a document the user produces (limited to what he likes/can type), fonts used to render externally-produced documents, and maybe even depending what the app using the dialog does
2. If you want to select font by faces Microsoft has defined a three-axis matrix in its WPF model whitepaper (slant, width, weight). People tend to forget the width axis when writing software
http://blogs.msdn.com/text/archive/2007/04/23/wpf…
3. Another way to classify fonts is the 5 generic CSS families that fontconfig reproduces (sans, serif, mono, cursive, fantasy)
4. Font aliasing will depend on the scripting so displaying what's aliased without knowledge of the script the user is going to use won't ever work
5. It is very necessary to hook the font selector to the PK font installer for discoverability (else people waste time installing fonts manually when they are already packaged)
6. It is very necessary to have a tab that displays font characteristics (format, supported scripts, licensing, etc) just a short preview is very insufficient to help people make an informed decision
7. IMHO the main problem of your mockups is they are ASCII/English oriented. The English script is about the simplest possible, there is almost no reason that what will work with English will work for other scripts
8. Please read attentively http://www.unifont.org/fontdialog/
I'm not sure the proposed dialog is very good usability-wise, but the listed requirements are very real and non-obvious for people that make no heavy font use (as in Arial everywhere)
Hey Nicolas! This is a wealth of information! I'll read through it all and try to apply. You're right on that I'm way too English/ASCII-centric, so I'm glad folks like you are helping to get me on the right track. Thanks 🙂
The mock-ups look nice, but when I'm browsing the font list for a suitable font for a Japanese piece of text, the AaBbCcDdEeFf preview is not going to help me much (but something like マイリンの猫が寝転んだ。 might). It would be nice if the sample text could be suggested by the font package (shifting the burden to the distributions) or a central list of representative samples (along with a sensible default).
The same goes for tagging fonts. Should this be done on the widget toolkit level? The font packages? (distribution level) An FDO project perhaps? (sharing this data across all free desktops and toolkits)
Also, how do we distinguish between locales? A locale selector defaulting to "any"? This won't make much sense for en_US, as nearly all fonts support that limited character set, but it would be nice for de_DE, nl_NL, etc. i.e., show all the fonts that support the characters needed for this locale. Of course, when does a font support ja_JP (Japanese)? If it supports the basic 2000-odd characters? 3000? 6000? Defined by the font? Defined by a central list?
Also, can the user search for fonts that include a specific character? (such as ū, €, ⿰, ß, or what have you) This seems like a common use case.
What are your thoughts on this?
It would be nice if the sample text could be suggested by the font package (shifting the burden to the distributions) or a central list of representative samples (along with a sensible default).
=> this list already exists in pango IIRC
Also, how do we distinguish between locales?
=> This is the wrong criterium, what matters is the script you want to write
Of course, when does a font support ja_JP (Japanese)
=> fontconfig already performs this analysis for you
So, all the low-level elements are already there, but the current dialog does not leverage them as it should. And the #1 requirement to leverage them properly is to make the font dialog contextual (do not display the same samples depending on the script the user is about to type/read ; of course that would require fixing the IM/layout switcher to a language/script switcher, with layout/IM a property of the language used, as Windows does)
Hello Nicholas, thank you for your comments.
> this list already exists in pango IIRC
Good to hear, I didn't know. That could be quite usable for this concept.
> This is the wrong criterium, what matters is the script you want to write
I agree as as far as Japanese is concerned, but what script is Dutch? Or German? In terms of this implementation, are they both the Latin/Roman script or more specific than that? Often a more graphical font will support basic ASCII, but anything beyond that (diacritics) is unavailable. Mind, if it becomes possible to quickly filter for only those fonts that actually implement the characters I request (by entering an optional argument, "ëéèê" or something like that, or may be the exact text I want to render with the font), that point becomes much less important I think.
Jeroen! What is my cat doing? It's lying on the ground? Hehehe. My name in katakana is モリーン though, it's pronounced "maw-reen" or "mo-reen" 🙂
Anyway
I think what I need to do in the mockups is show fonts from a few different character sets. I mentioned elsewhere in the comments, Alberto noticed that pango has an option to generate a preview based on locale or character set, so that would be the right solution I think for the previews under the fonts – it could make a call to pango for one appropriate to the language.
I'm not sure where tagging would go or how it would be stored. It would suck if the users had to do it on their own – tagging reall works better when you have a large body of people doing it, not just one poor person who loses it all when their machine gets reinstalled or something.
You make a good point that when a character set it supported, there's a lot of shades of grey there. Maybe some kind of bar graph or something to indicate coverage, eg in the case of Japanese I think the Japanese gov't sets guidelines as to what's the full base set of characters so maybe go based on that for Japanese… ?
I think searching for fonts that include a specific character is an awesome idea…. we'll try to figure out a way to work it in.
Great ideas, thank you so much!
Apologies, pronouncing someone's name correctly tends to be a challenge if not common in the languages you do speak. 🙂 (I have yet to meet a non-Dutch person who pronounces my name correct on the first try. Belgians and Germans seem to manage somewhat, but as for the Japanese… Well, I'll settle for any approximation of my name.)
Would it work if you placed options such as "Must contain these characters" and other more specific filters in an "Advanced …" or "More …" expandable panel of some sort? Or is this paradigm already obsolete? I think you are right in keeping the basic dialogue as simple as possible, but at least a possibility of more granular filtering might be good.
Another way may be to add a checkbox allowing the user to specify that any provided sample text should be completely renderable with the fonts in the resulting font list:
Sample text: [ „Wat een fantástiche ideeën!” ]
[x] Font must include above characters
The above Dutch sentence contains „ ” á ë, all characters not found in most graphic fonts. (useful if I'm designing a poster or what have you)
Is there any way to get the python source of Alberto's font selector? I'd love to see how to implement something like this in python.
Cheers!
He provided it here in an older blog post:
http://aruiz.typepad.com/siliconisland/2008/08/fo…
Hope this helps!
I like the last screenshot, very nice and much better than alberto's mockup, as it gives the most important thing – the font list including inline previews the most space.
Long time no see. One thing that we see a lot here at the City of Largo is that the font selector lets you pick fonts that break certain applications. Evolution has a place to pick a fixed font, and then gladly allows you to select NimbusSans 🙂 Then users are calling us because email messages designed for a fixed font are not lining up.
To me the calling program should pass to this widget a preferred type of font, possibly even more robust than fixed vs proportional. Should the user really pick 36 point for email? Have all of the widgets been tested in 40 point? So this workflow makes sense to me, and the info might help you during the design stage:
1) program calls font dialog and passes preferred type of font, and preferred font range .
2) By default user sees only those fonts initially., some kind of override button could be available to let them select something else with a warning message. We shouldn't be showing them things that break their software.
Anyway my 2 cents. Smarter software is greatly appreciated when you support users. 🙂
Nice, but it would be nicer if you replaced the drop-down with toggle buttons:
[Bold] [Italic]
Toggle buttons are more mouse-friendly than drop-downs. A drop-down requires 4 actions: point, click, find, click. A toggle button requires only 2 actions: point, click.
Cheers,
Yegor
The thing is, the font can be something like DejaVu, with a lot of styles, including Semi-Condensed, Ultra-Light, Oblique… you can't have so many toggle buttons.
Good point. As you can tell, I'm not a font guru. How about keep bold & italic in toggle buttons and the rest in the drop-down? The drop down will decrease usability, however. Maybe even the current style list is better.
A search box will definitely help to look for fonts whose names you know in advance. Inline font preview saves you another click. But style selection from a drop-down might cancel all these improvements by introducing extra navigation and clicking.
Yegor
The more I think about it the more it appears that the three-column paned view of the original dialog makes most sense.
1. To cut down the long list of families they should be collapsed as much as possible. That means all the fonts belonging to a family will have to be listed under the style widget. And that can make many styles. Much more than just bold and italic. DejaVu Sans alone has 9 styles on my system (Normal, Semi-Condensed, Ultra-Light, Oblique, Oblique Semi-Condensed, Bold, Bold Semi-condensed, Bold Oblique, Bold Oblique Semi-Condensed). And when you have professional sets installed you can get literally dozens of styles. This rules out Alberto’s toggle buttons. Your suggestion, the drop-down, list would be very unwieldy with that many styles. It would become a scrolling drop-down, which is awkward. A listbox seems much more natural. Additionally, it would be much easier to find a specific weight (e.g., thin) when going through the list, if one didn’t have to open the drop-down each time to check the members of the family. The point: Styles are too important to hide them away.
2. A list box is also a more natural choice to pick point sizes. Much more than a slider. You get a pre-defined selection of point sizes you can simply click, and you can enter a custom value. A slider is better used for continuous scales, not the quantal integers that are commonly used with point sizes. Inkscape uses a combo-box for point size, which achieves roughly the same, but it is a bit less efficient, requiring one more click.
Please consider these points and think about whether the three panes (or perhaps four panes to accomodate categories) make the most sense. The family list and the preview area definitely need improvement still.
[…] GTK Font Selector UI update round 1? « mairin a few seconds ago from xmpp […]
Thanks for working on this! It starts looking very nice already. Some quick thoughts:
The size slider looked a bit intimidating / technical to me. It might help to put the small indicator lines within the slider bar, not below it. And the Style dropdown might not be discoverable enough: many Word users are used to just pressing a 'B' or 'I' button.
How about putting the font selection not in a separate dialog, but in a pane / drawer attached to the document? This allows for more direct manipulation: you can see the font changes immediately reflected to the selected text. When I choose a font, I often already have typed some text and want to try some things out on it. Here's a quick sketch of the idea:
http://img193.imageshack.us/i/font20091016.png/
This looks nice!
I will take the opportunity to share some thoughts I have had about the colour of this bikeshed 😉
It is nice that Fedora has so many packages. But honestly: Some of them are high quality while others are more "funny" – or rather: They are good for different purposes. If would be very nice to have some filtering/ordering on their suitability for different purposes. Such a rating would however probably be flame bait and hard to implement in a good way.
Another thing I have been wanting is functionality for searching for "fonts similar to this and that font". It must be possible to apply some typographic metrics to fonts and filter/order by them. Such an ordering would probably make more sense than the traditional ordering by name.
I had a "use case" where I wanted a font for a particular purpose. I ended up installing _all_ the fonts in Fedora, and with fontmatrix I created a pdf with all fonts. Browsing that pdf turned out to be the best way to find the best font for my purpose.
Perhaps fontmatrix can be used as inspiration – and perhaps as an "advanced" font chooser. It seems like it has some of the classification functionality I'm dreaming of.
It would also be nice to have PackageKit integration so the font selector could show previews of uninstalled fonts and automatically install them if they are chosen.
[…] http://mairin.wordpress.com/2009/10/15/gtk-font-selector-ui-update-round-1/ แหล่ม !! […]
Something that would be nice as well is the ability to adjust character and line spacing, as in OS X.