business

Ja men va f-n Facebook

Anders Tufvesson 07 november 2013

Jag har varit inne på det här i ett tidigare inlägg där jag skrev om Facebook support. Jag har en sida på Facebook som ursprungligen startade som en incheckningspunkt. Jag tog kontroll över punkten och gjorde den till en sida. Så lång allt väl.

Men i maj gick det inte längre att uppdatera med statusuppdateringar eller lägga in foton. Jag fick följande meddelande:

Jag kan administrera sidan men jag kan inte lägga ut nytt innehåll.

Men det som riktigt retar mig är att Facebook inte har en support som kan fixa det OCH att jag då och då får lite glada tillrop i form av notiser from Facebook:

notis-facebook

 

Som jag skulle vilja… Men tyvärr kan jag inte. Tack Facebook, strö gärna salt i såren.

Etiketter:

07 november 2013 |

0 Kommentar

   Inga kommentarer än... Bli den första!

Tyck till! :)

När vi VERKLIGEN behöver veta något viktigt

Anders Tufvesson 12 juni 2013

EU-kommissionen vill dela in EU:s luftrum i nio zoner, i stället för att som i dag ha nationell flygledning i Europa. Det skulle göra att planen kan flyga rakare, vilket beräknas minska utsläppen med tio procent och sammanlagt ge besparingar på över 40 miljarder kronor per år.

Den 11/6 gick franska flygledare ut i strejk för att de inte tycker så. Idag den 12/6 fortgår strejken och för alla som är på väg någonstans eller som inom kort skall iväg bevakar läget. För mig var det extra viktigt då en familjemedlem är just på Shanghais flygplats och skall åka vidare till Paris om ett antal timmar och kommer fram kl 12:30 i morgon den 13/6.

Jag vände mig därför till det flygbolag som han skall åka med och letade information. Ingenting om strejken.

China Easter Airlines

Jag letade vidare genom att gå till Shanghais flygplats webbplats. Den var överbelastad och kunde inte ladda.

Jag lyckades då hitta en sökfunktion på China Easterns webb där flyget stod som status OPT. Jag är ingen expert så jag försökte googla och förstå vad OPT betyder men hittar ingen förklaring ens efter sökning via Google.

Jag började då fundera på hur olika flygbolag gör. Vilka har med information om strejken och vilka har det inte?

Skärmavbild 2013-06-12 kl. 14.36.31

SAS har inte med något. Ändå har de inställda flyg. Jag vet inte hur det ser ut för inloggade användare men i mitt fall är jag anhörig som vil veta mer men får inte reda på något.

Skärmavbild 2013-06-12 kl. 14.37.59

 

Lufthansa har inte heller någon information. Så beror det på att tyska bolag (och svenska) inte bryr sig om en liten strejk i Frankrike? Vad som skall tas med i ekvationen är att det också gäller flyg som går till och från Spanien och Portugal för de flyger ofta över Frankrike vilket medför att det är ganska många flyg som påverkas. Men jag hittade ett annat tyskt flygbolag som ger information.

Skärmavbild 2013-06-12 kl. 14.39.12

 

De skriver under ariberlin information nere till vänster ”Current information on the strike in France”. Air Berlin är kanske inte jättetydligt men informationen finns där.

Skärmavbild 2013-06-12 kl. 14.36.12

 

Ryanair har en ingång under bokningen med röd text. Informationen på sidan är också tydlig där de informerar om att strejken bara kommer att fortgå idag och att flygledarna återgår till sitt arbete klockan 6 på morgonen den 13:e. BRA!

Skärmavbild 2013-06-12 kl. 15.33.37

 

Till sist tar vi Norwegian som är tydligast på startsidan. Ett tydligt fält i toppen av sajten. BRA!

Frågan som jag ställer till alla som är ansvariga på en webbplats är hur sätter DU din webbplats i ”fokusläge”. Dvs. när du vill nå ut med en viss typ av extraordinär information och det är viktigt att besökarna får tag i den informationen snabbt.

 

12 juni 2013 |

0 Kommentar

   Inga kommentarer än... Bli den första!

Tyck till! :)

Designa för Windows

Anders Tufvesson 01 december 2011

Något jag väldigt sällan stöter på i min yrkesroll just nu är att göra desktop-applikationer för Windows. Under alla mina studieår på universitetet hade jag inte en enda gång möjlighet att läsa någon kurs i människa datorinteraktion och i gränssnittsdesign. Jag är enormt intresserad av dessa ämnen och väldigt iver att lära mig mer.

I förra veckan fick jag ett litet miniuppdrag att skapa en enkel desktop-applikation till en av våra kunder inom finanssektorn. Idén är superenkel. Man matar in två värden, man väljer ett filnamn och man hämtar hem en fil från nätverket. Användarna av den här applikationen är personer med varierande datorkunskaper men med en sådan här enkel applikation kan man inte göra fel, eller?

Jag tänkte dela med mig lite av några do’s and don’ts när det gäller gränssnittsdesign av desktop-applikationer. Kanske kan det inspirera er att se på gränssnitten på ett annat sätt och även kanske bygga gränssnitt annorlunda. Först och främst vill jag göra det klart att det jag skriver här inte passar i alla sammanhang – det finns alltid undantag. Dessutom är jag väldigt allergisk mot att lägga in saker i en applikation ”för att det går”.

Om man designar en applikation för ett specifikt operativsystem (exemeplvis Windows®, MacOS® eller en specifik fönsterhanterare till Linux) så ska man följa de guidelines som är uppsatta för detsamma. Genom att göra gränssnittet harmoniserat med övriga element i systemet blir ovana användare tryggare och dessutom erhålls en känsla av att applikationen hänger ihop med systemet. Vilket är väldigt viktig användarupplevelse enligt mig.

Läsordning

Det finns många studier på hur användare tittar på en ny skärm de inte sett förut. En kunskap om detta underlättar oerhört när man gör ett nytt gränssnitt. Bilden nedan visar hur användaren tittar från vänster till höger och uppifrån och ner. I länder med annan läsordning än vänster till höger kan detta variera.

Bild: Microsoft Corporation

På grund av att den vanlige användaren tittar så här ska vi också fylla på med information från vänster till höger. Den viktigaste informationen till vänster och mindre viktig information till höger. Jobbar vi med formulär ska dessa fyllas i från vänster till höger i första hand och i andra hand uppifrån och ner.

Jag ska visa en bild som jag tycker är så givande. Jag har lånat den från Microsoft Guidelines för gränssnittsdesign. På bilden ser vi ett gränssnitt där ordningen man ska utföra uppgifterna är väldigt i oordning. Det är jobbigt för en användare att arbeta i det här formuläret eftersom man först och främst inte direkt ser i vilken ordning det krävs att man gör saker men också för att det tar onödigt med tid att hoppa mellan de olika fälten.

Bild: Microsoft Corporation

Om vi ordnar om fälten i det här formuläret enligt läsordningen ovan så blir det som bilden nedan. Direkt ser man i vilken ordning man förväntas fylla i formuläret. Det här är ganska enkelt och tänka på och man behöver inte ha några layout-kunskaper eller någon känsla för layout för att lyckas. Det är bara rena regler! Det gillar jag!

Bild: Microsoft Corporation

Ordningen vänster till häger gäller också när man bygger verktygsfält. Fyll på med de mest använda ikonerna till vänster och fortsätt sedan åt höger med fallande signifikans och användning. Tänk också på att skärmbredden (i pixlar) varierar för varje användare vilket gör att för vissa användare kan knappar i höger-kanten döljas när fönstret blir mindre. Detta bör man lösa genom att låta de knappar som döljs kunna visas i en nedfällbar meny, det är oftast inte rekommenderat att skapa en ytterligare rad eftersom detta bryter tanken om att de mest använda verktygen skall ligga till vänster.

Bild: Apple Inc.

Alignering (aligning)

En viktig sak när man arbetar med gränssnittsdesign är att hålla designen så alignerad  som möjligt. Detta hjälper ögat att sålla och sortera i informationen. Tittar du på bilden kanske du instiktivt känner att det är svårt att hitta informationen i fönstret. Ju fler kolumner (grids) vi lägger till desto mer avancerat blir gränssnittet.

Bild: Microsoft Corporation

I nästa bild reduceras antalet kolumner till 4 i stället för 9. Gränssnittet känns ”luftigare” och det är lättare för ögat att hitta informationen vi är ute efter. ”Less is more” skulle man kunna säga här. Det här är också en enkel regel man alltid kan applicera, och gäller även på webben faktiskt.

Bild: Microsoft Corporation

Menyer och menyval

Något annat som är ganska enkelt att arbeta med är segment i menyer. Här finns ingen direkt regel, men kommandon som logiskt hör i hop grupperas ihop. Exempel: Nytt, Spara, Öppna, Stäng hör ihop, och Klipp ut, Kopiera, Klistra in hör ihop. Genom att segmentera menyn så blir det flera fall enklare att snabbt hitta det man söker.

Bild: Apple Inc.

Det är högt rekommenderat att arbeta med kortkommandon. Bilden ovan visar en menyer på MacOS® men principen är den samma även i Windows®. Det vi bör tänka på när vi tilldelar kortkomandon är att man gör det enligt ”gängse standard”. Det finns en visst antal kortkommandon som användare vanligen vill utför samma operationer i olika program. Detta är exempelvis; kopiera (CTRL+C), Spara (CTRL+S), Avsluta (ALT+F4), Öppna (CTRL+O). Om ditt program exempelvis använder CTRL+S för att stänga programmet utan att spara pågående arbete blir användaren ganska förvånad (och kanske irriterad) när han använder det kommandot och förväntar sig att det skall spara hans arbete. Dock är detta en helt annan historia, som ni kan läsa mer om på Microsofts webbplats!

Inaktivera otillgänliga val

En viktig detalj i ett gränssnitt är att enbart visualisera de verktyg som fungerar att använda. Ett formulär kan ha många kontroller som kanske kan användas vid ett visst givet tillfälle.

Det enklaste, och kanske bästa sättet, att göra detta är att inaktivera de kontroller som inte är tillgängliga. Det gör att användare inte försöker använda dem eller lägger energi på att fylla i dem.

Nästling

Jobba gärna med att nästla element som hör i hop, exempelvis genom att lägga alla kontroller för att söka i en gruppering vid namn ”Sök”. Det gör det lättare för användaren att hitta vad han eller hon söker. Det är också bra att indentera element som är underelement till en annan kontroll, som enbart är tillgängliga när ett överordnat element är aktiverat.

Bild: Microsoft Corporation

Det man dock aldrig ska göra är att nästla simpla element. Med det menar jag att man exempelvis aldrig ska lägga ett textinmatningsfält i beskrivningstexten till en kryssruta. Personer med nedsatt syn och som använder skärmläsningshjälpmedel kan ha svårt att uppfatta sådana konstruktioner.

Bild: Microsoft Corporation

Försök i stället att omformulera meningen så att du kan lägga textinmatningen sist eller på en ny rad.

Spacing

Vi har ofta problem med språkanpassning (localization). Ord och meningar har olika längd på olika språk och ibland får vi inte plats med etiketten innan själva datan börjar.

Ett enkelt knep för att komma förbi detta är att ta för vana att alltid lägga den beskrivande etiketten ovanför dataetiketten. Då har vår beskrivning möjlighet att växa sig mycket större innan den inkräktar på något.  Det finns också studier (enligt ”Jävlaskitsystem”) som visar på att det är lättare för ögat att hitta den information man söker när etiketterna är ordnade på detta sätt.

Bild: Microsoft Corporation

Till slut kan jag tipsa om att alltid använda de spacing-guidlines som Microsoft Visual Studio® föreslår när du placerar ut kontroller. Det hjälper dig till att bli en bättre UI-designer för Windows. Dessutom är den så smart att den hjälper dig att hålla dina aligneringar. Så om bara du gör alla knappar och inmatningsfält som hör till samma gruppering lika stora så kommer Visual Studio ® hjälpa dig med resten!

Mer?

Är du nyfiken på mer? Då kanske du kan läsa några av de här:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511275.aspx
http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Windows/Windows.html

http://javlaskitsystem.se/

Jag har lånat de flesta bilder från Microsoft Corporation och några från Apple Inc. för denna artikel. Om det är så att Microsoft eller Apple anser att jag använt deras material olovligt kommer jag omedelbart att ta ned dem. Jag drog mig för att göra egna bilder eftersom jag tycker bilderna är så talande och bra gjorda.

Etiketter:, , , , ,

01 december 2011 |

1 kommentar

  1. Kommentar av Carita G den 02 juni 2016 kl: 8:54
    Carita G skriver:

    Tack för denna artikel, väldigt bra infomation om hur man skapar en desktop applikation

Tyck till! :)

Driftsäkerhet, tester och fel

Anders Tufvesson 16 november 2011

Hur skriver man kod som anses var driftsäker och vad är det – Är det kod med väldigt lite fel? Kod som inte behöver underhållas så ofta?

Jag reflekterar ofta om den tid som finns att lägga ner på ett kodstycke. Ofta är det så att beställarna vill ha jobbet utfört till så liten kostnad som möjligt (vilket jag förstår) och då blir det minimalt med tid på varje sak. Men ”vad kostar detta i längden?” brukar jag tänka då.

Som utvecklare har man alltid en viss tid till tester, det är så oerhört viktigt att testa det man skapat så att det uppför sig som förväntat. Man testar ofta normalfallen och några yttre fall som man kan tänka sig inträffar. Det brukar räcka väldigt långt. Men som alltid finns det massor av undantagsfall som man kanske inte räknat med och var ska man dra gränsen? Allt beror, tycker jag, på ändamålet och hur viktigt det är för kunden att systemet i alla skeden går smärtfritt.

Det är oerhört vanligt att vi skriver så kallade enhetstester till våra metoder, vilket testar att våra metoder beter sig som vi förväntar sig vid de vanligaste indatafallen. När det kommer till integrationstester så blir vi ofta mer frikostiga hur vi utför dem, här burkar det nämligen gå åt en del tid eftersom integrationstesterna är svåra att utföra. Något många beställare inte är beredda att lägga allt för mycket tid på.

När det däremot gäller acceptanstester så är beställare ofta mer benägna att lägga tid. Acceptanstestet är deras kvitto på att de fått vad de beställt men den här typen av tester testar i stort sett aldrig ytterligheterna.

Vi bygger sällan, om ens aldrig, system som är ämnade för att skydda eller rädda liv. Det gör att man kan fokusera mycket mer på att komma framåt i utvecklingen än att kontrollera för fel, vilket är viktigt i många av de branscher vi arbetar med (framförallt webb). Det här ses ofta positivt på från ett beställarhåll eftersom man erhåller något nytt hela tiden. Men å andra sidan här vill beställarna ha en hög tillgänglighet, applikationen skall vara driftsäker.

Men tillbaka till ursprungsfrågan; hur skriver vi kod som är driftsäker?
Hur konstigt det än kan låta tycker jag att det här är ett delat ansvar. Framförallt skall vi förklara varför vi vill lägga tid på de olika typerna av tester, vi är experterna, men å andra sidan måste beställare av applikationer vara medvetna om att tester får ta tid. Hur mycket vi skall testa och vad vi ska testa måste tas fram i perspektiv till verksamheten.

Det finns flera sätt att få något väldigt driftsäkert, och det vanligaste måste vara att man är många som delar på ansvaret att kontrollera att en viss del av kod utför det den skall. Och att utföra många och långa tester för att se till att den uppför sig som man förväntar sig i alla möjliga situationer.

Som jag skrivit i ett tidigare inlägg måste det finnas utrymme i en budget för underhåll av applikationer. Det gäller både webb- och desktopapplikationer. Omgivningen förändras något så oerhört, framförallt på webben där det kommer nya webbläsare och nya krav från beställaren varje dag. Men även desktopapplikationer behöver underhållas för att passa nya operativsystem och nya krav. Lägger man inte ner tid på att anpassa och underhålla applikationerna under tid kommer man tillslut till en punkt där det blir ett allt för stort jobb att göra.

Statens Järnvägar lanserade 1980, efter tio års utveckling och tester, ett system förhindra olyckor i tågtrafiken. Systemet hette, och heter fortfarande, ATC. Här fanns (och finns) det ingen tolerans för fel eller situationer som man inte räknat med. Sedan 1980 har det kommit tre versionuppdateringar av ATC men det det tog 13 år innan en första versionsuppdatering kom (1993 släpptes ATC2).

Hur kommer det sig då att ett sådant system klarar sig från större underhåll av koden?
Jag tror, utan att vara någon expert, att det handlar om två saker. Först och främst är det en väldigt statisk och sluten miljö men också att man har lagt ner otal timmar på testning av alla möjliga fall. Att man la ner tio år av utveckling och tester innan man införde det i stor skala på alla tåg är nog en av framgångssagorna. Efter 30 år med systemet är det så inkört att förarna nuförtiden helt förlitar sig på systemet, man kör som det heter på ”pipet” och litar fullt ut på att ATC-systemet varnar vid för höga hastigheter, röd signal eller systemfel. Hör man inget ”pip” är det bara att gasa på!

Men för oss som inte har ett slutet system eller kan lägga tid på tester?
Vi kanske får acceptera att vi kommer att ha fel i våra applikationer till en viss gräns och att vi måste vara beredda på att kontinuerligt lägga tid på att rätta de fel som uppkommer. När det kommer till driftsäkerheten finns det inga genvägar, och jag vet att man ibland brukar lösa prestandaproblem på webbplatser genom att låta dem starta om allt som ofta. En fräsch start löser ofta mycket konstiga tillstånd i ett system men är ingen bra utväg. I dessa fall kanske man ska fundera på om det inte är värt att lägga tid på att hitta felen och rätta dem.

Utvecklare: varför skriver ni fel över huvud taget?
Den frågan får jag ibland och den är alltid lika intressant att svara på. Det finns ingen, eller i alla fall nästan ingen, utvecklade som medvetet skriver kod som man vet är fel. Däremot finns det alltid massa undantag på in och utdata som kan ställa till det. Det värsta en utvecklare kan handskas med är indata från okända källor (som användare), för man vet aldrig hur den ser ut. Utöver detta har vi fall där data har blivit korrupt eller andra hjälpfunktioner man använder sig av får problem med att köra. Kanske är det slut på RAM-minne, slut på diskutrymme, fullt på stacken, för långsam nätverksanslutning, kommunikationsproblem med I/O, ja allt detta kan hända men kanske inte är något man kontrollerar när man ska addera två tal. Jag vet att jag överdriver lite granna nu, men i realiteten skulle vi behöva kontrollera så otal många fall för att verifiera att allt fungerar som det skall om vi ska täcka alla möjliga fel som uppkommer. Varje fall måste dessutom hanteras på olika sätt, sådant tar tid!

I bland händer det förvisso att vi skriver fel också, men det är sällan med flit. I avancerade applikationer finns det alltid möjlighet till tankevurpor.

Så slutligen så kan jag konstatera att vi skulle behöva lägga mycket tid på tester om vi vill få allt problemfritt från början, men att vi åtminstone lägger tillräckligt med tid för att hitta de värsta felen och sedan löser resten när de inträffar.

Kuriosa:
För den intresserade finns ATC i version 1, 2, 2.1 samt 2.2. De stora skillnaderna är mellan ATC1 och ATC2 där är frikostigare med att lossa en automatisk driftsbroms som ATC har slagit till vid för hög hastighet/närmande av stoppsignal om den märker att föraren försöker bromsa själv. Dessutom ändrades vad som bänder om flera hastighetangivelser tas emot, tidigare använde ATC den lägsta medan i den nya versionen den som senast togs emot. De två senaste uppdateringarna 2.1 och 2.2 syftar enbart till att lösa specifika problem. 2.1 möjliggör för systemet att ta emot körbesked via radio som ett komplement till balisier på marken. Det gör att man kan ge nya körbesked (ex. höjd hastighet) om en ex. signal längre fram slår om från rött till grönt. På så sätt  kan man häva ett besked om hastighetsnedsättning innan man når nästa signalen vilket resulterar i att tåg kan köras snabbare och mer effektivt. Version 2.2 löser problem för tåg som åker över Öresunsbron och in i Danmark där man har en annan typ av ATC. Omkopplingen mellan systemen måste ske automatiskt, vid exakt rätt tillfälle, i 200km/h.

Källor:
http://techworld.idg.se/2.2524/1.160472/med-atc-systemet-gar-taget-som-pa-rals

Etiketter:, , , , ,

16 november 2011 |

3 Kommentarer

  1. Kommentar av Andreas Eriksson den 16 november 2011 kl: 19:35
    Andreas Eriksson skriver:

    Mycket bra skrivet och en hel del sanning.

  2. Kommentar av Rikard Elofsson den 17 november 2011 kl: 8:59
    Rikard Elofsson skriver:

    Kan gissa att du gärna läser Jörgen Städjes alster, han gillar också att grotta ner sig i ATC-systemet… :)

  3. Kommentar av Henrik Bäck den 17 november 2011 kl: 9:13
    Henrik Bäck skriver:

    Ja, han skriver mycket bra om diverse system. Läste om kärnkraftverket i Oskarshamn tidigare, mycket intressant.

Tyck till! :)

(Över-)anpassade system

Anders Tufvesson 18 oktober 2011

Kravspec När man som kund skaffar ett nytt system finns det ju ett antal kriterier som detta ska svara upp mot, såsom användarvänlighet, funktionalitet, säkerhet etc. Ofta skriver man milslånga kravspecar på just allt detta för att inte missa några viktiga funktioner och försöker täcka in allt det som man just vill ha.

Ett system som kan svara upp mot alla dessa krav måste ju vara riktigt bra, eller? Jag menar, ett sånt system måste ju vara väldigt anpassningsbart, vilket innebär att varje kund har sina egna speciella ”måste ha”-saker. ”Klickar jag där så ska den här pluppen här uppe tändas, men bara när klockan är före 12, så måste det vara annars kan vi ju inte jobba!”.

Vad händer då när Systemet ska uppgraderas efter 3-4 år och det visar sig att leverantörens ”jodå, alla anpassningar följer med vid en uppgradering” inte längre rikigt stämmer för det visar sig att ”jo, alltså standardanpassningarna följer ju med, men inte de specialarna som vi har gjort för just er”?

Har man då varit lite för överivrig i sina anpassningar kan det lätt bli så att man sitter där och blir lite lätt nervös för hur det ska gå. Och det kan vara lika mycket ditt eget fel som leverantörens fel som inte berättade vad det kan innebära ur ett förvaltningsperspektiv. Det kanske inte alltid är av godo att ett system kan göra ”allt”, minst lika viktigt är hur systemet ska kunna förvaltas och uppgraderas och hur den kostnaden korrelerar mot hur viktigt att alla dessa ”special-pluppar” måste finnas på plats.

Dock är det ju trots allt så, att med en sund inställning vad gäller anpassningar och med en bra relation med din leverantör kan ditt system nästan innehålla precis ”allt” du egentligen behöver.

Etiketter:,

18 oktober 2011 |

0 Kommentar

   Inga kommentarer än... Bli den första!

Tyck till! :)