Home • Perspective • Tutorials • Standards • Symbols • Web Standards • Links • About
During my usual Monday volunteering at the local Red Cross, I was involved in a conversation about the dates printed on the food and drinks we keep in order to feed the victims of local disasters (water, GatorAide, snack bars, and the like). It turns out that many had been confused by what the dates on the packages meant. Some thought they were the “Sell by” date, some the “Best if used by” date, and some the “Use by” date—all of which have different meanings according to which government document or food producer you ask. Apparently, our supplier (SYSCO) has decided to mark all of its packaging with the expiration date, but has also decided to not mark that the date is the expiration date. The simple addition of the ISO “use-by” symbol (an almost empty hourglass) to the date would clear up this confusion.
And therein lies the problem. There is no clear, consistent definition of these terms, so the fact that most consumers have the wrong understanding of them is quite unsurprising. The most important thing to realize, is that none of these imply food past that date is unsafe. Even the “Use by” date is simply when the manufacturer expects the food to no longer have the flavor or quality they expect. An egg used after that date is unlikely to whip as well or have as firm a white when fried, but does not magically become unsafe to eat.
In my opinion, a major contributor to this confusion is the failure to include multiple dates on packages, and make sure that all food producers are using the same definition of the dates. And it might not surprise you that I think symbols would help, too!
In order to be consistent across state and country boundaries, every effort should be made to ensure the harmonization of the meaning and presentation of these dates. There are several standards bodies and specifications that should be mashed-up.
The most constraining standard is that of barcodes. The GS1 organization defines the implementation of 1D and 2D barcodes when used on retail goods, and two of its most recent standards, “GS1 DataBar” and “GS1 DataMatrix” are both capable of encoding product dates along with UPC (a.k.a. EAN/GTID) numbers. Any dates placed on the package should be capable of being expressed in these standards.
Another standard to be integrated is the ISO symbol library, which includes symbols for “date of manufacture” (ISO 7000-2497) and “use-by date” (ISO 7000-2607), but not symbols for “Best Before”, “Production Date”, “Sell-By Date”, or “Packaging Date”.
All these need to be coordinated with the definitions of the terms. The U.S. The National Conference on Weights and Measures (through NIST) publishes the “Uniform Open Dating Regulation”, which is meant as a nationwide guideline for some of these terms. It defines “Sell-By” and “Best if used by”.
There are some arguments against continued use of the “Sell-by” date, since this is really only of interest to stores for stocking purposes. But eliminating this would force stores to use the “Best before” (optimum quality or flavor) date, which previous research has found to be ambiguous for stock rotation purposes (Open Dating of Foods, page 41). So we really need “Sell-by”, “Best-Before” (still acceptable quality), and “Use-by/Expiration” (degraded safety or nutrition) dates to appear on food.
And the distinction and consistent definition of these two latter terms is the most important aspect to improved open dating, in my opinion. The combination of these two dates will help to indicate to consumers that there isn’t a hard cut-off date, but rather, a period of degradation. This will aid consumers in deciding when a product should be discarded or is still safe to eat, without creating a fear that results in an inordinate amount of non-spoiled food being discarded, to the detriment of our landfills and pocketbooks alike.
More to come on this topic soon.
…
I've decided to start a new series here on PG—commenting on one graphical symbol a week. My goal in adding this feature is to begin a stronger push for the better design and use of symbols.
This week’s symbol is ISO 7000-2635: Destination home—Designed to be used on automotive navigation systems to activate a route calculation that will take you home.
At the recent PechaKucha Night San Francisco, one of the first slides I presented to the audience was of this very symbol, and my questions for them were, “Have you seen this before?” and “What does it mean?”. There were no answers or hands for the first question, and none of the several answers shouted out for the second were anywhere close to accurate.
I find a whole host of problems with this symbol. First, out of a crowd of 350 people at PechaKucha, not one of them had seen this before. OK, so it's San Francisco, and many don't have cars, but these are designers. This means that despite being standardized, virtually none of the GPS navigation manufacturers know about the symbol, or have even thought about the most common navigation task: going home. Also:
…
I recently needed to make a couple of presentations at a local the Red Cross preparedness exercise, and like the persnickety guy I am, thought it would be best to use one of the the official Red Cross PowerPoint templates.
But when I tried to use the template, I discovered enough problems with its design that I decided to redesign it from scratch, so that it had the same design, but looked better and was easier to use.
This was the first time in a long while I had created a PowerPoint template from scratch, and in setting out to find the best way to build each part of it, realized that enough of what I was doing was so poorly understood by many users that it deserved to be shared outside of my own head.
The result is Making Better PowerPoint 2003 Templates, which I hope will help you create better presenations.
PowerPoint has a great many useful features, but the process of using them to create a good-looking and operating presentation template is veiled behind a curtain of ambiguity and obscure help files. The program’s documentation does an almost adequate job of explaining how most of its features work, but never really teaches you how to properly design a template.
This tutorial aims to not simply teach you how to create a template, but why the particular steps and methods are used, using my recreation of the American Red Cross template as a demonstration. I point out little subtleties, such as selecting the proper variant of OpenType fonts instead of simply using the bold button, how some of the animation schemes might interact with your color scheme, and how to properly size raster images to look their sharpest at a particular projector resolution.
…
I should have done this long ago, but just got the bee stuck in my bonnet.
When I first decided to attempt to support desktop and handheld browsers without duplicating content or using browser sniffing, I used the most basic method I could think of; using XHTML 1.0 for the main pages, but using XHTML Basic 1.0 for the individual postings and archive.
This gave me a rich page design, but reverted to a simplistic, almost no markup, design for the blog permalinks, while I began work on the CSS. But realizing that this was not an ideal situation, and after discovering that it was possible to scroll the content on my existing design when displayed on the iPhone by using two-finger events, I decided to revert the fancy design for all pages.
But with that done, it is now time to work on a CSS style sheet for handheld browsers. You would think specifying this would be simple, but no! None of the handheld browsers (except for Opera Mini) support the obvious handheld media type. And worse yet, Apple is under the mistaken impression that the handheld media type is meant for dumb browsers and not appropriate for the iPhone Safari browser. Instead, you must resort to a more complicated media query that relies on CSS 3.0 support (which isn't even a completed specification!).
David Storey covers all the ugly details in his iPhone and developing for mobile posting from mid-2007. The problem is that enough other browsers are broken that this query works for Safari but causes problems with IE. The belief that the handheld media type should only be applied to phones with WAP browsers is idiotic and shows a lack of understanding of how CSS media selectors work.
Media selectors don’t lobotomize web pages into sub-5K WAP pages, they simply specify a different set of CSS rules. A handheld CSS stylesheet might drop the background image and multi-column layout, but aside from any image substitution, it’s not going to significantly change the number of bytes that are downloaded; just the appearance of the page. This is the media selector that the iPhone should have used. Relying on an unfinished spec for critical functionality was not the right thing for Apple to do.
More rants on this topic once I’ve spent some time trying to find a method of switching CSS that will work nicely.
…
The recent announcement by the GSMA of broad support behind a USB-based universal mobile phone charging system raises hope of a universal charging solution, but also raises many problems that few have discussed.
The first question is who is driving this standard, and what is it called? The Open Mobile Terminal Platform has a specification titled Common Charging Solution. The GSMA references this in their GSMA Universal Charging Solution, but doesn't define the relationship between the two. And then there is the USB Implementor's Forum's USB 2.0 Battery Charging Specification. All three organizations use different names, but are they really the same thing? And specifications are notoriously difficult to read, but the OMTP one is one of the most obtuse and under-specified I've read in years.
I am a huge fan of the concept of a universal charging connector, but there are many problems I see with the current state of the above efforts.
First, the selection of the Micro-USB connector is troubling. Yes, it's smaller than the Mini-USB connector, and was designed for a higher number of mate cycles (up to 10,000!). But it was also designed to have higher retention than Mini-USB, and nothing in its design addresses blind mating. In fact, the specification adds an option for a latch.
So this universal charging specification is one step forward and at least one step backward. A charging adapter that doesn't support the kind of low-force, drop-in chargers that have been made ubiquitous by the iPhone relegates users to having to once again fish out the charging cord that has dropped down below the desk or nightstand before they can get their nightly recharge.
All of these specifications are lacking guidelines for how to indicate the charging status of a phone or the capabilities of the USB host or charger. Standard USB can only supply enough power for a very slow trickle charge, 100 mA or 500 mA. The USB 2.0 Battery Charging Specification provides for a way to provide up to 1500 mA (1.5 amps) for charging, but there are no rules for how to indicate that a USB port or USB charger is capable of this increased power delivery, which is needed to provide fast charging. There needs to be an icon on or next to a USB port to indicate it is capable of this, and a light or other indicator when it is actually in this mode.
How many people commenting on the OMTP/GSMA USB charging efforts have read the USB 2.0 Battery Charging Specification? The specification is extremely complex (as it needs to be, since it is adapting USB for a purpose it was not initially designed for), and based on the past incompatibilities between mobile phones that used USB charging (think charging a Motorola Razr V3 with a Blackberry charger, or a few other combinations), I expect that there will be numerous USB chargers and mobile phones that incorrectly implement the spec. The result will be chargers that don't charge all phones, phones that can't be charged by all chargers, and perhaps worse.
And then there is GreenPlug. This group is on a parallel track to implement universal USB charging, but with a technology that requires an enhanced USB connector and plug with additional pins and logic.
In the year plus GreenPlug has been around, I have not seen any devices ship that use its technology. OK, so there's one charger, but where are the end devices implementing it? Although it seems reasonable that the new OMTP/GSMA initiative will get significant traction, the existence of multiple competing methods and poorly written specifications will continue to cause incompatibilities among “universal” USB charging solutions.
Complete failure of the USB charging initiatives is unlikely, but it is clearly not a great solution. Improvements can and should be made to the standard, but I think it is already time to look forward and begin designing a better replacement. Perhaps one that can solve some additional end-user problems, and not just provide another way for the industry to save cost by providing inferior technology.
…
I guess this is what happens when I stop involving myself in the development of Web standards. Am I the only one on the planet that understands content negotiation and how important it is to the W3C’s admirable vision of “One Web”?
In advance of attending the Web 2.0 Expo, I thought I should catch up on recent happenings and make a quick little post on the important issue of a single URL working for both desktop and mobile browsers.
I was pleasantly surprised to find the latest efforts by the BPWG—the Mobile Web Best Practices 1.0 - Basic Guidelines and the W3C mobileOK Basic Tests 1.0.
When I first skimmed the documents, I thought they were exactly on track. But looking at two key details, I see an omission and an error that dooms us to needing separate URLs (or domains) for mobile content for some time to come. The error is simple; the test case mandates an HTTP accept string that says the browser equally prefers plain HTML and WAP 2.0. Since plain HTML should have a higher quality setting on the server than WAP 2.0, the content negotiation rules mandate a browser that sends this string be send plain HTML. !!!!
Include an Accept header indicating that Internet media types understood by the Default Delivery Context are accepted by sending exactly this header:
Accept: application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif
A simple change to the above string, such as specifying the WAP 2.0 (XHTML Mobile Profile) MIME type as q=0.2 would have avoided this problem.
Even more fundamental to that problem, is the selection of XHTML Basic 1.1 as the standard document type for mobile browsers. Because this was selected instead of XHTML Mobile Profile, there is no way to activate the decade-old documented method of content negotiation based on MIME types; at least not if I want to send XHTML 1.1 to desktop browsers and XHTML Basic 1.1 to mobile phones (which is indeed what I want to do).
Here is the problem. Content negotiation relies on the mime type being different for each variant you want to serve, but look at this:
XHTML 1.1 MIME type:application/xhtml+xml
XHTML Basic 1.1 MIME type:application/xhtml+xml
OK, so there is a way to differentiate these two MIME types, but it's not pretty:
application/xhtml+xml;profile=http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd
I don’t really have a good solution for a fix at this point. One possible solution is to better specify content negotiation in an RFC so that pre-defined strings can be used in the profile to specify different types of XHTML. Another would be to use the level attribute instead of profile, and map integers to XHTML types (shudder, but it would work). Or maybe the W3C can just register application/basic.xhtml+xml as the MIME type for XHTML Basic? That, I think, is the simplest solution.
Don’t even get me started on the .mobi top-level domain!
…
I need to buy a handful of DTV converters. Forget, for the moment, that my FCC coupons expired before I finished my research into the best models for my needs. Let’s just deal with the simple issue of finding a place to buy the converter box I selected.
After whittling down my list of must-have features, it became apparent that the RCADTA809 was the ideal device. But I can't find any retailer that carries the unit, and I can't even find any mention of converter boxes on the RCA Web site! (Er, it’s not even listed on the “real” RCA TV equipment (read: Audiovox) Web site.)
The features I care about are few in number, but high in value:
Finding the union of all these features and reading the reviews of its predecessor quickly led me to the RCA line of converters. Aside from its program guide and image quality getting good marks (only the Zenith models consistently reviewed higher for image quality), RCA seems to be the only brand with a universal remote control.
RCA’s previous models, the DTA800A, DTA800B, and DTA800B1 all have marks against them. The first two have the flaw of replacing the already programmed channels when scanning for new ones, making it impossible to receive stations that require antennas to be turned. And at least one person who purchased both the DTA800B1 and the DTA809 says the 809’s receiver is more sensitive, picking up distant stations better.
Alas, none of the usual e-tailer suspects have the DTA809—not Newegg, not Amazon, not even a Google shopping search. And none of the big-box stores have it listed either—Best Buy, Target, Wallmart, Sears, K-Mart, etc. And even the slightly older DTA800B1 is nearly impossible to find.
Even worse, the big-box stores closest to me have a miserable selection—typically a hundred boxes of the same model from just one manufacturer.
Of course,
…
It's Monday, so I spent the usual 4:30 pm to 11:30 pm at the Red Cross--working on the comm van before and after the monthly disaster services meeting, discovering yet another reason why it needs to be gutted and begun anew.
I had previously learned the hard way that adding an internal shore power cable wired full-time into the AC panel while there's still an external shore power inlet, just because the previous custodian couldn't be bothered to buy the $100 50A 125V to 15A 125V adapter isn't such a hot idea. Er, actually, the fact that it was a hot idea was exactly the problem! That's the second time in my life I've felt 125 Volts (don't ask about the first).
Tonight's lesson was from one of our local OES guys, Jeff Norris, who raised his eyebrows when I explained the pneumatic mast's control box operation to him. The problem is the fact that the up position--raise--isn't momentary. Enough TV ENG van crews have electrocuted themselves by raising masts into high-voltage power lines that OSHA mandates that this switch be momentary. And we had to take the control panel apart and trace wiring to discover that the down position did more than just lower the mast--it also keyed a coax relay that switched which antenna went to the 47 MHz radio. This was documented, but not on the switch. It is documented at the radio, which is not visible at the mast control panel.
Both of these problems indicate what I think is a fundamental problem created by those designing physical, electrical, electronic, and software things today. Much of their important operating procedures require reading the manual. There are fundamental UI design issues around how to design things that are intuitive, but the lack of designers placing context-sensitive documentation directly on things is a huge problem that is related to how designers (and their teachers) operate philosophically.
…
I'm trying to save Fridays for writing about Fabulous things, instead of Frustrating things, but an experience I just had necessitates postponing my daily themes a bit.
At the Burlingame Red Cross office I've been volunteering with for the last three years, we have a Cushcraft 220 MHz antenna that we're about to lend to the chapter's Concord office, so they can diagnose their 220 setup. In the process of disassembling it, I broke one of the phasing stubs off. Since someone else had broken one earlier, this left the antenna with just one--not enough to work right.
So I visited the Cushcraft Web site, or tried to. But it was gone, redirecting to the parent company's site, Laird Technologies site instead. Gone were all of the long-known URLs pointing to the Cushcraft product pages, support pages, and all of the careful tagging their Webmaster had done to get Google to present a helpful search result that could take you directly to the page you were after.
It's fine to absorb a purchased company's content into your site, but you must not break any of the URLs that search engines have, or that people have bookmarked (or memorized). Doing so is fundamentally egotistical, arrogant, and self-destructive. Laird has instantly alienated all of their existing Cushcraft customers. Why would you spend $90 million to buy a company, and then two years later, tell all of their existing customers to bleep off?
But it gets worse, and indicates how clueless Laird is about technology. The problems I've found are numerous, but here are the highlights:
Note to Cushcraft customers: Use the frustrating new Laird site or the Archive.org Wayback Machine to find and download all of the manuals and technical information you need before Laird's clueless Web team deletes the last remnants, and start looking for another antenna supplier (not Larsen; they're owned by Laird now as well).
Note to Laird stock holders and fund managers: go look for signs the company is making life difficult for customers in other ways. It may be that this stupidity is contained within the IT department, in which case the problem is easily fixable. But if it's origin is in marketing, that's likely going to be an entrenched mindset that will continue to do stupid things like this, and not just with the Web site.
Note to Laird: Keep these idiots away from the Radiall-Larsen Antenna Technologies Web site and products. I'm a huge fan of the Larsen antennas, and you don't want to destroy a key asset of yours. The antennas are very well made, aesthetically pleasing, and the company has come up with some real innovation (such as the NMO-HF system) that you want to encourage, rather than squash and hide.
…
I've spent another miserable couple of hours trying to figure out how to get Illustrator to do something simple--fill a region with a color. Something I've been able to do with AutoCAD since last century.
But Illustrator has only had this feature since CS2, and has some of the same teething problems AutoCAD had early on. A region that visually appears to be closed isn't good enough; it has to meet all of the inane internal rules, some of which it can't tell me about. I can't even duplicate the error I got earlier, so can't Google for a solution, and all it tells me now, after clicking on a region it can't fill, is that, "If you wish to add the paths to the Live Paint group, click the Add Paths button...". Quite frustrating when I've already selected all of the paths available.
Of course, the map I'm using is part of the problem. It started out life as an ABAG Smart Growth map, from which I deleted all the extraneous data to leave just the city boundaries. But this map is funky--all of the labels consist of 6+ copies of the text, some white and some black, to give a knocked-out look. And most of the city boundaries are duplicated, triplicated, or worse. And don't even get me started on the strange way (using many, many, rectangles) that most of the fills were accomplished with.
But Adobe knows there are many crappy source documents such as this one, and should better design Illustrator to deal with their properties. For instance, why can't Illustrator show me where the gaps are, and then suggest a few options on how to close them? Why can't it use its 3D prowess to show me an exploded view of the stacking order? Real interactive feedback like this would go a long way towards making the software easier to use.
Labels: usability
…
♲ℹ⃝
|
PetesGuide.com follows the official Web specifications, and is compatible with any desktop or phone browser that correctly supports XHTML. Deficient browsers, such as Internet Explorer and most mobile phone (WAP) browsers, may have problems, however. Browser Requirements:
❃ ❃ ❃ Socialize with Me
❃ ❃ ❃ Blogroll |
