Usability http://blog.samat.org/taxonomy/term/52/0 en The GNOME font dialog, why? http://blog.samat.org/2007/02/18/the-gnome-font-dialog-why <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>Fredico M Quintero pointed out <a href="http://primates.ximian.com/~federico/news-2007-01.html#font-sizes">some serious flaws in <span class="caps">GNOME</span>&#8217;s font configuration dialog</a>; the <a href="http://primates.ximian.com/~glesage/wiki/doku.php?id=font-config-dialog">Novell Product Design wiki also describes some problems</a>. In a sentence that fits in with what I believe is <span class="caps">GNOME</span>&#8217;s “simplicity mantra”, <b><span class="caps">GNOME</span> should just get rid of its useless, confusing fonts configuration dialog</b>.</p> <p>Why does it have a font configuration dialog anyway? Well, unfortunately, <span class="caps">GNOME</span>&#8217;s setting daemon completely ignores several fontconfig settings and instead uses its own settings for things like antialiasing type, whether hinting is used, <span class="caps">DPI</span>, etc. You need the font configuration dialog to change these settings, or you have to dig through gconf. Most of this was put in place probably to subvert a broken X setup; instead of implementing these hack-ish workarounds <span class="caps">GNOME</span> should instead push to fix X&nbsp;instead.</p> <p>It&#8217;s extremely difficult to discern the difference between the different types of antialiasing. <span class="caps">GNOME</span>&#8217;s dialog doesn&#8217;t let you select arbitrary text, or let you render text in-place so that you can quickly compare between different antialiasing styles and subpixel orderings. These settings, along with <span class="caps">DPI</span>, are unlike the rest of the settings in the font configuration dialog because they don&#8217;t apply immediately. They only affect newly started applications, and the dialog does nothing to alert you of&nbsp;this.</p> <p>Do users really need to be able to select subpixel ordering from a dialog? There are very few <span class="caps">LCD</span> monitors that do not use an <span class="caps">RGB</span> subpixel ordering. The very few people who rotate their <span class="caps">LCD</span> monitors into portrait mode (including me, see my past article <a href="/weblog/20060419-misery-with-online-reading-of-pdfs-and-the-need-for-portrait-monitors.html">Misery with online reading of PDFs and the need for portrait monitors</a>) would use <span class="caps">VRGB</span>. Why not just set <span class="caps">RGB</span> subpixel ordering if the user is using an <span class="caps">LCD</span>? <span class="caps">VRGB</span> if their display is rotated? Again, these are things <span class="caps">GNOME</span> could discover by querying&nbsp;X&#8230;</p> <p>Lastly, do users need to change the fonts used by their <span class="caps">UI</span> in the first place? The majority of Windows and MacOS X users don&#8217;t deviate from the defaults at all—why would <span class="caps">GNOME</span> users be given a choice through this confusing dialog? <span class="caps">GNOME</span> instead should use the fontconfig aliases “Sans”, “Sans Serif”, and “Monospace” rather than letting users choose fonts. A fresh <span class="caps">GNOME</span> setup already uses these aliases as the defaults&nbsp;anyway.</p> <p>Of the settings in the font configuration dialog users may actually want to set, whether to use antialiasing or not is the only one that sticks out to me as needing an option. I think that the dialog could be replaced with a simple, descriptive checkbox somewhere that read “Antialias text” that would toggle all the heuristics I&#8217;ve described&nbsp;above.</p> </div></div></div><div class="field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Topic:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/tag/Linux" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Linux</a></div><div class="field-item odd"><a href="/tag/Usability" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Usability</a></div><div class="field-item even"><a href="/tag/GNOME" typeof="skos:Concept" property="rdfs:label skos:prefLabel">GNOME</a></div></div></div> Mon, 19 Feb 2007 02:23:55 +0000 Samat Jain 136 at http://blog.samat.org Yes, GNOME is limiting! http://blog.samat.org/2007/02/18/yes-gnome-is-limiting <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>There&#8217;s been a lot of fallout from <a href="http://applications.linux.com/article.pl?sid=07/02/16/1937237">Linus&#8217; latest criticism of the <span class="caps">GNOME</span> desktop</a>, with which I complete agree. I feel as if I need to comment on some of the&nbsp;responses.</p> <p><a href="http://ubuntu.wordpress.com/">Carthik Sharma</a> writes in <a href="http://ubuntu.wordpress.com/2007/02/17/of-apples-and-oranges-gnome-and-kde/">Of Apples and Oranges, <span class="caps">GNOME</span> and <span class="caps">KDE</span></a>:</p> <blockquote> <p>I dread having to find something, since it most definitely will be placed in some non-intuitive&nbsp;sub-menu.</p> </blockquote> <p><span class="caps">KDE</span> has no control over where applications decide to place&nbsp;themselves.</p> <blockquote> <p>I like the way <span class="caps">GNOME</span> display fonts on the screen. I don’t want to have to change every little variable to get the perfect&nbsp;system.</p> </blockquote> <p><span class="caps">GNOME</span> pioneered use of fontconfig; in fact, lately, <span class="caps">GNOME</span> has been pioneering the use of many next-gen APIs and technologies (e.g. <span class="caps">AIGLX</span>, Beryl, etc). But Qt/<span class="caps">KDE</span> have also been using fontconfig for several years now—what&#8217;s&nbsp;different?</p> <p>Interesting enough, there has been criticism about <a href="http://primates.ximian.com/~federico/news-2007-01.html#font-sizes">how <span class="caps">GNOME</span> handles fonts</a>. Taking points from that article, <span class="caps">GNOME</span>&#8217;s font configuration is a&nbsp;mess:</p> <ul> <li>What&#8217;s a “Terminal” font (it should be called “Monospace,” as it is in <span class="caps">KDE</span>, because this is how it&#8217;s also used throughout&nbsp;<span class="caps">GNOME</span>)?</li> <li>What does “size” mean (apparently, it&#8217;s not what you&nbsp;think)?</li> <li>Why do I care about the subpixel ordering of my fonts&#8217;&nbsp;antialiasing?</li> <li>Why would I need to set fonts at all (see my weblog entry <a href="/weblog/20070218-the-gnome-font-dialog-why.html">The <span class="caps">GNOME</span> font dialog, why?</a>)?</li> </ul> <p><span class="caps">KDE</span> is no different than <span class="caps">GNOME</span> in trying to provide “sensible” defaults, defaults that its developers have decided are intrinsic to a “perfect desktop.” But, what the developers have decided is the perfect desktop may not be your perfect desktop—and here lies the essence of Linus&#8217; argument, and the difference with <span class="caps">KDE</span> and <span class="caps">GNOME</span>. With <span class="caps">KDE</span>, you may have an option to make a setup “perfect”; with <span class="caps">GNOME</span>, quite often the option won&#8217;t exist and you are limited to what the powers that be decided was perfect for them, not you. This is Linus&#8217; argument: <b><span class="caps">GNOME</span> is limiting</b>.</p> </div></div></div><div class="field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Topic:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/tag/Linux" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Linux</a></div><div class="field-item odd"><a href="/tag/Usability" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Usability</a></div><div class="field-item even"><a href="/tag/Ubuntu" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Ubuntu</a></div><div class="field-item odd"><a href="/tag/GNOME" typeof="skos:Concept" property="rdfs:label skos:prefLabel">GNOME</a></div><div class="field-item even"><a href="/tag/KDE" typeof="skos:Concept" property="rdfs:label skos:prefLabel">KDE</a></div></div></div> Mon, 19 Feb 2007 01:28:00 +0000 Samat Jain 135 at http://blog.samat.org Misery with online reading of PDFs and the need for portrait monitors http://blog.samat.org/2006/04/19/misery-with-online-reading-of-pdfs-and-the-need-for-portrait-monitors <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>In the process of writing a term paper for a class, I&#8217;ve been paging through many research&nbsp;papers.</p> <p>Unfortunately, many of these research papers are only available for reading via <acronym title="portable document format"><span class="caps">PDF</span></acronym>. Even for those papers that have full text on a normal webpage, complex login and authentication systems (i.e. I can only access said page through my university library) force me to save PDFs to facilitate later&nbsp;reading.</p> <p>PDFs are really miserable for reading on the computer. My&nbsp;gripes:</p> <dl> <dt>Fixed font&nbsp;styles</dt> <dd>Many PDFs use serif fonts, which are generally difficult to read on screen (though fine on print media). Some irate designers even create PDFs that use &#8220;Times New Roman,&#8221; which despite it being default on many web browsers is ugly and difficult to read. In a web browser, you can change it; in a <span class="caps">PDF</span>, you are forced to suffer with&nbsp;it.</dd> <dt>Fixed font&nbsp;sizes</dt> <dd>Font sizes are fixed in PDFs, you cannot change them. Often when reading on screen, fonts are just too large, or are too small. This is compounded&nbsp;with&#8230;</dd> <dt>No&nbsp;wrapping</dt> <dd>Text is statically laid out, so you are completely reliant and sizing your window and adjusting your zoom to be able to read a block a text, or stuck with moving your scrollback back and&nbsp;forth.</dd> <dt>Columns</dt> <dd>Computers have scrollbars. Columns make absolutely <i>no</i> sense when you can scroll. The worst case comes up when you combine columns <span class="caps">AND</span> scrolling: you have to scroll down to finish reading a column, and then scroll back up to begin reading the top of the next&nbsp;column.</dd> </dl> <p>Usability expert Jakob Nielson thinks so too: in 2003 he had a column <a href="http://www.useit.com/alertbox/20030714.html"><span class="caps">PDF</span>: Unfit for Human Consumption</a>.</p> <p>It seems that some of these problems stem from a mismatch in orientation. Computer monitors are generally landscape; PDFs and printed media are&nbsp;portrait.</p> <p>And computer monitors just keep getting wider. While widescreen is nothing short of awesome for movies and television, its not that useful for computing. The classic use case is the accountant with a wide spreadsheet: but how many people have wide spreadsheets? Because most people use computers to create content in a portrait orientation, and that most content we read expands <i>downward</i> rather than to the side, it seems as if it would make sense if monitors were a portrait orientation rather than&nbsp;landscape.</p> <p>Fortunately, this is easy to try out now. Most <span class="caps">LCD</span> monitors swivel into portrait orientation with a flick of the wrist. Microsoft Windows and Linux (through the XRandR extensions) have provided orientation switching support for a few years as&nbsp;well.</p> <p>But it&#8217;s not yet usable by the mainstream. For example, on Linux with nVidia&#8217;s binary drivers, running in portrait means losing out on accelerated 3D as well as multimonitor support, things many people (including myself) are not ready to&nbsp;lose.</p> </div></div></div><div class="field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-inline clearfix"><div class="field-label">Topic:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/tag/Software" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Software</a></div><div class="field-item odd"><a href="/tag/Computer-Hardware" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Computer Hardware</a></div><div class="field-item even"><a href="/tag/Usability" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Usability</a></div></div></div> Wed, 19 Apr 2006 06:53:21 +0000 Samat Jain 86 at http://blog.samat.org