Webbsäkra färger konstaterat döda
En gång i tiden använde man bara de 216 webbsäkra färgerna för webbplatsdesign. De lever fortfarande kvar, och jag har själv varit osäker på om man kan strunta i dem, och välja fritt bland alla miljontals färger. Nu har jag konstaterat att de webbsäkra färgerna är övergivna. Fortfarande är dock samtliga färger på denna blogg webbsäkra.
Webmonkey gjorde en undersökning år 2000 (som nu verkar vara borttagen), där de kom fram till att av de 216 färgerna var det bara 22 som var ”riktigt webbsäkra” för skärmar med 256 färger. Standarden med säkra färger var alltså misslyckad redan från början.
Jag skrev ett litet skript som gick igenom stilmallar från ett par kända webbplatser och analyserade de angivna färgerna. Resultatet var inte vad jag hade väntat mig – webbsäkra färger används helt enkelt inte i någon vidare stor utsträckning. (Notera att skriptet endast gjorde en enkel sökning med reguljära uttryck. Säkert missade det några färger här och där, men de allra flera borde ha analyserats.)
- World Wide Web Consortium: 71% av färgerna var webbsäkra
- Regeringen: 68%
- Flickr: 41%
- Sveriges television: 30%
- 456 Berea Street: 27%
- Technorati: 24%
Jag frågade Roger Johansson från 456 Berea Street, vad han anser om webbsäkra färger:
Min inställning är att det är helt omöjligt att få färger att visas identiskt på olika skärmar. Inte ens om man ställer två skärmar bredvid varandra är det enkelt att justera dem så färger återges exakt likadant … Det är en kamp man inte kan vinna, så då är det bättre att lägga sin energi på annat tycker jag. Jag gör så att färger ser bra ut på en bra skärm, kollar att det går att läsa innehållet även om kontrasten eller ljusstyrkan är lite knasigt inställd, men sen släpper jag det. Det går liksom inte att kompensera för felaktigt inställda bildskärmar.
Om man ska fylla en stor yta med en enda färg och det råkar passa med en webbsäker färg så visst, då är det bra om man använder den. I de fall någon använder en bildskärm med 8 eller 16 bitars färgdjup blir det ändå hyfsat för det mesta. Men självklart är det bra att kolla hur en design blir i 256 färger. Det finns ju alltid en risk att text blir svårläst.
By the early years of the 21st century, driven by the needs of video games and digital photos, personal computers typically had at least 16-bit color and usually 24-bit (truecolor). Even mobile devices had at least 16-bit color, driven by the inclusion of cameras on cellphones. The use of ”web-safe” colors fell into disuse, but persisted as folklore.
Riktlinjer för högsta möjliga läsbarhet på skärm
Forskning vid Stephen F. Austin State University kring läsbarhet på datorskärm, visar på ett antal riktlinjer som bör följas. Undersökningarna gjordes visserligen under 1990-talet, men är naturligtvis ändå giltiga. Komplettera dessa undersökningar med den om radlängd, så har man en ganska bra uppsättning verifierade riktlinjer för webben.
För högsta läsbarhet på en datorskärm bör du hålla dig till följande:
- Hög kontrast (framförallt svart på vitt, blått på vitt och svart på grått – se alla kombinationer)
- Negativ kontrast (dvs. svart på vitt, istället för vitt på svart) – speciellt för äldre läsare
- Ingen textur bakom texten (ex. bakgrundsbild)
- Större textstorlekar (undersökningen anger 12-14 punkter)
- Större radavstånd (undersökningen anger 1,5-2 rader)
- Radlängder på c:a 95 tecken
Mest intressant var att positiv kontrast, trots sin popularitet, är sämre för läsbarheten. Exempelvis den populära produkten WriteRoom har grön text på svart bakgrund, och har alltså både positiv och låg kontrast. Trots att den är framtagen just för att skriva långa texter är den inte läsvänlig. Man har alltså tänkt mer på att produkten ska vara snygg än bra. (Typiskt Mac-användare, måste jag tillägga med ett flin.)
Placera etiketterna ovanför inmatningsfälten
UXmatters har gjort ett test av etikettplacering i formulär, där användarnas ögonrörelser registrerades. För att summera, ska du placera etiketten rakt ovanför inmatningsfältet, och inte använda fet stil på etiketten. (Precis som jag har valt att göra i kommentarsfältet här nedanför – vilken tur!) Två andra, vanliga placeringar testades också: med etiketten till vänster, antingen vänster- eller högerjusterat. Dessa placeringar kräver mycket mer ögonrörelser från användarna, och är därför sämre.
Varför du inte bör använda CAPTCHA – och alternativen
CAPTCHA står för Completely Automated Public Turing Test to Tell Computers and Humans Apart, och innebär att en bild med text visas, och du som besökare uppmanas att fylla i vad det står i bilden. Det används för att kontrollera att du är en människa och ingen automatiserad spamrobot, exempelvis för att få kommentera artiklar på bloggar. Idén är att människor kan urskilja svårläsliga bokstäver och siffror bättre än ett program. Detta är inte en bra lösning, och i den här artikeln ska jag förklara varför.
Först och främst är de störande för alla besökare. Om jag vill kommentera en artikel på en blogg vill jag inte fylla i nonsens i en ruta, utan att det ger mig något tillbaka. Spam är blogginnehavarens problem, inte besökarnas! Besvära inte dina besökare bara för att du inte lyckats hitta någon bra lösning på spamproblemet. Det är direkt användarfientligt att lämpa över problemet på användarna – och det finns bättre lösningar!
Dessutom är det inte så effektivt säkert som man kan tro. Det finns ett flertal automatiserade program som knäcker CAPTCHAs med 88-100% tillförlitlighet. Det innebär att spammare kan ta sig igenom skyddet i stort sett när de vill. För att motverka detta görs texterna mer och mer oläsliga, med lägre kontrast, vridna bokstäver, störande streck och punkter och så vidare. Jag har själv ibland väldigt svårt att tyda vad det egentligen står i rutorna. På grund av alla CAPTCHAs har spammare också anlitat billig arbetskraft för att skriva spam-kommentarerna manuellt istället.
Naturligtvis är detta svårt eller omöjligt att tyda för personer som är blinda, har nedsatt syn (och i vissa fall nedsatt färgseende). Men även dyslektiker kan ha svårt att klara en CAPTCHA. Det som skulle skilja människor från spamrobotar blir istället en skiljevägg mellan människor med och utan handikapp – och det är direkt diskriminerande.
Vissa implementationer av CAPTCHA är dessutom bristfälliga och går att knäcka utan att tolka själva bilddatat. II-stiftelsens CAPTCHA för att få göra en utökad sökning bland domännamn har jag exempelvis knäckt på ett mycket enkelt sätt. Jag tror jag ska återkomma till det i en senare artikel, jag ska bara reda ut om de kommer polisanmäla mig först. (Jag har aldrig utnyttjat detta ”hack”, men vet hur man skulle kunna kringgå deras kontroll. Det är en skillnad.) Efter mailväxling med IIS har de nu täppt igen ”hålet” som jag upptäckte.
På vissa större webbplatser har man börjat med ljud-CAPTCHAs som komplement till dessa visuella. Då får man ett antal tecken upplästa istället – men det är ännu lättare att knäcka med ett automatiserat program. Därför gör man det svårt att höra bokstäverna, precis som med bilderna. Personal på CNET lyckades inte höra vad Hotmails ljud-CAPTCHA sa, så detta är uppenbarligen ingen bra idé.
Andra röster som kritiserar CAPTCHA:
- Wall Street Journal: ”The visually impaired have long decried these codes …”
- World Wide Web Consortium ”CAPTCHA … is unnecessarily damaging to the experience of users with disabilities.”
- 456 Berea Street: ”Besides having accessibility issues, the use of CAPTCHA in my opinion suffers from usability problems and should be avoided.”
- Six Apart: ”If the only way to comment on your site is by solving an image-based CAPTCHA, you have a serious accessibility problem.”
- CNET News.com: ”It seems that they have jumped on a technological idea without thinking through the consequences for the whole population”
- Tales from the SharpSide: ”I’m sick of CAPTCHA. It straight-up doesn’t work.”
Alternativa lösningar
Det bästa är att hitta tekniska lösningar som inte ålägger besökaren att göra något extra. I vissa fall kanske det inte är möjligt, och då kan man exempelvis låta besökarna lösa ett logiskt pussel av något slag. Genast har man då gjort det väldigt svårt för grupper med nedsatta kognitiva funktioner, så det är inte mycket bättre. W3C nämner ytterligare några alternativ, och Daniel Lopresti vid Lehigh University tar upp en hel drös alternativ (PDF).
Som sagt är det bäst med icke interaktiva lösningar, som exempelvis ett Bayesiskt spamfilter eller olika heuristiska tekniker för att försöka avgöra om besökaren är en människa eller en robot. Det finns faktiskt framgångsrika tekniker inom båda dessa områden, se exempelvis Akismet och Bad Behavior. Tillsammans kan dessa undanröja i stort sett all spam, och du kan låta besökarna få kommentera utan att behöva sköta din spamkontroll.
Dagens lästips
Några artiklar från andra bloggar och webbplatser, som jag tycker är läsvärda:
- Vi överskattar förmågan att använda nya funktioner, Blind höna (via Användbart.se): om en undersökning som visar att vi gärna förköper oss på produkter med alltför många funktioner, och underskattar tiden det tar att lära sig dem.
- Best Buy, Bad Design, Signal vs. Noise: ett bra exempel på (faktiskt) korkad, men inte alls ovanlig design. Man kan alltid lära sig från
dåligaexempel på dålig användbarhet. - We can’t leave innovation up to our users, Creating Passionate Users: konstaterar att innovation och revolution inte kan komma från användarna själva, utan från oss utvecklare. Användarna vill få aktuella problem lösta, men de ser inte längre än så.
- Writing words vs. writing software, Signal vs. Noise: en intressant jämförelse/liknelse mellan att skriva program och skriva litteratur.
- When the ”best tool for the job”... isn’t., Creating Passionate Users: om varför vi väljer fel utvecklingsverktyg, och att vi istället borde använda verktyg vi tycker om att använda.
$100 för att installera WordPress
I need a Word Press Blog installed along with a theme (template).
1) The website has fantastico, (host is gator) so installation ”theoretically” should be easy. 2) Install the theme and make sure everything is working properly. 3) Two sets of easy to follow instructions are necessary: a. How to make posts (the extreme dumbies guide) b. How and WHERE (EXACTLY) to install google ad code and other affiliate code etc.
Att någon är villig att betala upp till $100 för att få WordPress installerat på sitt webbhotell är både obegripligt och typiskt. Obegripligt, därför att det finns både en och annan gratis WordPress-tjänst. Typiskt, därför att det visar hur svårt det faktiskt är att förstå hur man installerar också lättanvända program som WordPress. Installationen tar ett par minuter och är busenkel – tycker jag.
På webbplatsen Rent A Coder kan man annonsera ut programmeringsjobb och liknande som man behöver ha gjorda. Sedan erbjuder programmerare sig att utföra arbetet för en viss summa pengar. Ovanstående är ett jobb som du eller vem som helst kan tjäna pengar på. (Rent A Coder är förresten ett mycket bra exempel på en otroligt rörig och oöverskådlig webbplats. Ta en titt, vettja.)
Blir Javascript-virus framtidens plåga?
Säkerhetsexperter vid företagen SPI Dynamics och WhiteHat Security har upptäckt ett nytt hot: Javascript-virus. Det ligger på en webbsida och aktiveras när du öppnar den med din webbläsare. Observera att virusen inte utnyttjar en sårbarhet eller ett säkerhetshål i en specifik webbläsare eller operativsystem, utan att det är ”gamla hederliga” virus. Javascript kan dock inte skriva till filer på din dator, så den typen av skador kommer inte kunna ske. Däremot kan virusen komma åt allt som har en webbserver – och det blir hela tiden fler och fler webbservrar i hemmen.
A successful attack could have significant impact. For example, it could scan your home network, detect a router model and then send it commands to enable wireless networking and turn off all encryption, Hoffman said. Or it could map a corporate network and launch attacks against servers that will appear to come from the inside, he said.
Tyvärr ser det mörkt ut inför framtiden. Virusen går inte att undvika genom att uppdatera Windows eller använda Firefox istället för Internet Explorer. Alla webbläsare med Javascript kan drabbas – och det verkar som att vi kommer få dras med denna plåga framöver:
”All our protection recommendations are server-side,” Grossman said. Site operators should fix cross-site scripting flaws and validate any user-submitted JavaScript. ”The users really are at the mercy of the Web sites they visit. Users could turn off JavaScript, which really isn’t a solution because so many Web sites rely on it,” he said.
Attacks aren’t widespread, Grossman said. ”JavaScript malware is still cutting-edge, and nobody really knows what you can do with it,” he said. ”Liken it to the early days of an e-mail virus – that’s where we’re at now. I think we’re going to see (many) more attacks.”
Dagens lästips
Några artiklar från andra bloggar och webbplatser, som jag tycker är läsvärda:
- Stiff asks, great programmers answer, Sztywny Blog (via OSNews.com): intervjufrågor om programmering, där några riktigt stora namn är med och svarar, exempelvis James Gosling, Guido van Rossum och Peter Norvig.
- Recycle Bin not enough, Microsoft adds ”Previous Versions” support on the file system level, Ars Technica (via Slashdot): om den nya funktionaliteten i Windows Vista, som automatiskt sparar alla versioner av dina dokument. En bra hjälp, eller ett hot mot integriteten?
- Torvalds critical of new GPL draft, CNET News.com (via Slashdot): Linus Torvalds kritiserar det nya utkastet av licensen GPL version 3.
- Text mining the New York Times, Roland Piquepaille’s Technology Trends (via Slashdot): om hur forskare med en ny algoritm har lyckats göra en ämnesanalys av 330 000 nyhetsartiklar på bara några timmar.
- Can Your Programming Language Do This?, Joel on Software: pedagogisk genomgång av fördelarna med programmeringsspråk med så kallade ”first-class functions”.
Problemet med framtida bloggartiklar och pingning i WordPress
När jag använde bloggverktyget WordPress för min tidigare blogg, skrev jag ett insticksprogram (”plugin”) som bara pingade när artiklarna publicerades första gången, och inte när de uppdaterades (Smart Update Pinger). Det har blivit mycket populärt, men löser inte alla problem med pingning. Framförallt får jag många brev från bloggare som ofta skriver artiklar där de anger ett framtida publiceringsdatum. Exempelvis skriver man då många artiklar före semestern, och låter dem dyka upp på bloggen med jämna mellanrum när man är bortrest. Då uppstår genast ett problem med pingning.
Eftersom mitt insticksprogram inte känner av att publiceringsdatumet är i framtiden pingar det så fort artikeln är skriven och sparad. Då kan man från pingtjänsten följa en länk till denna framtida artikel, och läsa den med en gång (se diskussionen i WordPress forum)! Det är en brist i WordPress, att alla publicerade artiklar alltid är tillgängliga, till och med de med framtida datum – men de visas inte i översikterna.
Man vill förstås som bloggare att pingtjänsterna ska pingas när en framtida artikel blir tillgänglig, men det är inte så enkelt. Pingning för engelska bloggar sker ofta mot många tjänster, och det kan ta 30 sekunder till över en minut. Jag pingar c:a fem tjänster, och det tar runt tio sekunder för det mesta. Detta sker dock i ”min” process när jag publicerar artiklar, och besökarna märker ingenting. Om pingningen ska ske någon gång i framtiden, kommer den sättas igång i en besökares process – och då får besökaren vänta medan pingtjänsterna pingas. Det är självklart inte bra med fördröjningar, men det är värre än så: om besökaren avbryter laddningen, avbryts pingningen. Om flera besökare dyker upp ungefär samtidigt, kan flera omgångar pingningar gå iväg. Ingen bra lösning, alltså.
Den enda lösningen, såvitt jag kan se, är att man använder UNIX-verktyget cron. Då körs ett program med jämna mellanrum, som kollar om det är dags att pinga tjänsterna. Om så är fallet, sker pingningen i den processen och påverkar aldrig besökarna. Det är dock ingen bra lösning rent användbarhetsmässigt, eftersom cron är hopplöst nördigt och svåranvänt – och måste konfigureras i kontrollpanelen på webbhotellet.
Etiketter
Flitiga kommentatorer