Re: Screenshot quality in KDE announcements
Carl Symons <[email protected]>
| Newsgroups | gmane.comp.kde.events |
|---|---|
| Message-ID | <54C7B200.5010604__17529.8183029101$1422373417$gmane$org@gmail.com> |
On 01/27/2015 06:40 AM, Eike Hein wrote: > > Hi, > > we once again put out a major release announcement using screenshots > with obvious UI defects (e.g. the kscreen one where the orientation > bar in the display delegate isn't clipped by the rounded rect and the > vertical text alignment is off) - frustratingly, some of which have > already been fixed in the beta (including those). > > This is a real problem because it causes negative feedback in venues > where the announcement is discussed every time. It's not a small pro- > blem, either, because visual quality is one of our major reputation > weak spots, so people actively scan our material for defects to con- > firm this widely-held belief. > > There is a bigger problem underlying this which starts in our dev > process, but for promo purposes we should try to put our best face > forward and use high-quality screenshots. They show the actual pro- > duct; they're perhaps the most important part of any communication > we do. > > Could we discuss some strategies to avoid this problem in the future? > > I'm imagining a QA process+checklist: > > * Promo puts announcement screenshot package together ahead of time. > * Promo checks those screenshots for obvious rendering and UX > defects and tries to alert developers to them. > * Promo runs those screenshots by the VDG list to employ the VDG for > bug spotting as well. > * We try to fix this problem and re-take the screenshots in time. > > We already do these things for announcement texts, but screenshots > are often done ad-hoc and last minute, and it shows. They deserve > no less quality control than the text. > > > Cheers, > Eike > > They deserve no less quality control than the text. Or the software. Related to legal principle--false in one, false in everything. So this is not just about screenshots...poor quality anywhere suggests poor quality everywhere. This issue is not just about process+checklist. We need to have someone(s) who is willing to take responsibility for screenshots. Whoever does this needs to install the new version prior to its release and follow the guidelines below. This is not difficult or time-consuming. Any takers? Anyone willing to do a non-technical task that contributes directly to KDE quality? Carl From Nuno Pinheiro, maker of pretty things >>> Guidelines for release screenshots: >>> - Use default wallpaper >>> - Use only two or three colors for anything that's not a photo >>> - Resolution 1280x720 >>> - Use the same font everywhere. Oxygen or Liberation Sans is preferred; other sans fonts are workable. >>> - Use the default wallpaper >>> - Hinting style set to full. Even if you like big fonts, the result is >>> much sharper if your hinting is set to full. >>> - Use a smaller font size like 8 or 9. Small fonts have a thinner trace that makes the font thickness be exactly 1 pixel. If your font thickness is not 1, then you are in trouble. Low hinting style and large fonts make traces of about 1.3 - 1.5 thickness that result in blurry looking fonts. They are not only bad looking, they tend to produce headaches as your eyes try to constantly focus the font. >>> - Don't use bold. Bold fonts are not as readable as normal fonts because the width of the trace is usually larger than 1 and smaller than 2 producing blurry results. >>> - Make your fonts more greyish than blackish; gives much better sharpness results. _______________________________________________ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.