Mathilde Hoeg

  • ThumbnailVi omtaler ofte dagens børn og unge som “digitalt indfødte” eller “den digitale generation”. Den australske kulturteoretiker Mackenzie Wark gik endda så langt som at postulere at

    “Generations are not defined by […]

  • ThumbnailUser Centered Design er et populært begreb for designmetoder, der inkluderer brugeren som en del af processen i alt fra idégeneration til testning af prototyper eller forfining af det endelige produkt.

    Fordelen […]

    • Man har jo ofte hørt historier om fokusgrupper der siger et og gør noget andet, som f.eks. at sige at de foretrækker produktet hvis det er gult og når de forlader lokalet tager de et test-eksemplar i sort i stedet for det gule, så det er virkelig et vigtig budskab du har. Jeg er selv stor tilhænger af brugercentreret design og en vigtig ting i arbejdsprocessen er at sørge for, at alle forstår at det ikke er det brugeren siger som er vigtigst, men det resultat de ønsker (og det kræver ofte en del analyseren af svarene for at finde frem til det egentlige behov og derefter det bedste design som kan opfylde det/de behov).

  • Det svære ved netop sådanne tematikker er jo altid at det er svært at kommunikere de teknologiske aspekter, på en måde så det bliver alment tilgengængeligt. I den forbindelse er John Olivers interview med Edward Snowden ganske fortrinligt! https://www.youtube.com/watch?v=0zg7_4AMXGs

  • ThumbnailAgile Manchester lovede at være en hands-on konference…holdt det så? Nu har jeg været afsted i to sprængfyldte dage, med post-it notes og klistermærker…Og jeg har lært hvorfor man skal være ligesom Nemo og […]

  • ThumbnailJeg har tidligere lovprist konferencer som grobund for netværk og vidensdeling. En af de absolut bedste indgangsvinkeler til networking, der er givende og fagligt indholdsrigt, er selv at være taler ved en […]

  • Masser af de IT-systemer vi bruger til dagligt bruges ikke af én bruger foran én skærm på et fast sted. Context-aware, eller kontekstbevidste computer systemer og applikationer forsøger at tilpasse sig en bestemt […]

  • Det er altid en fornøjelse at læse dine indlæg. De er velskrevne og velovervejede. Tak for det 🙂

  • Years ago I ended up in a discussion with someone over whether programming was art or not. He claimed that it was merely a tool for a practical purpose while I claimed that there was beauty in code, unique to the medium.

    Screen Shot 2014-10-18 at 23.40.46

    Andrew Sorensen’s live music/code performance at Goto 2014

    Watching Andrew Sorensen’s live performance doing GOTO proved me right. Sorensen makes music from programming real time systems in real time with real time output. Changes in the code could be perceived instantaneously. Sorensen would listen to the music and change the code based on this.

    Live editing is tough – suddenly timing matters, not only in the execution but also in our input. All changes that are made are based on the immediate feedback that we get, the music that we hear. The observed state is what leads us to the change in the first place. And the changes become irreversible, once they are out there we can’t take them back; no matter the result.

    In this way Sorensen added beats, harmonies, and melodies to create a musical performance. All the while the audience could watch the music being coded on screen while listening to the resulting music. When the performance ended the resulting code was not the experience that we had all shared. As Sorensen noted, the changes in the code WAS the performance.
    Programming is a journey
    But what about the everyday programming? The code we write day-to-day based on requirements and user-needs; where’s the art in that?

    For Sorensen the art was in the changes made, the immediacy of the output combined with the tools and objectives of the programmer. In this way the art was in the journey.

    Creating good code is a journey; there will be starts and stumbles and lessons along the way. The experience of coding is a journey for the developers, but it results in an end-product for one or more users. This end-product, however, is rarely a journey for our users. Just as with Sorensen’s performance, the end-product is not the experience; not for the developers and not for the users. No end-product ever is.

    The artist/programmer has had an art-
    journey, but the moment the code leaves the artists hand it becomes a mere craft. It is always the recipient who must take this particular piece of craft and turn in into art.

    Developers are artists. Never make your code anything less than art.

  • Du er en person på nettet, der bare virkelig gerne vil købe en lommelygte. Du finder den perfekte og trykker “køb” og bang! Straks møder du den berygtede formular. Lyder det bekendt? Formularer på internettet står ofte midt i mellem hvad du, som bruger, gerne vil opnå og hvad udbyderen af hjemmesiden eller servicen har behov for. Mange mennesker hader at udfylde disse formularer – hvilket kan føre til at mange vælger at logge ind via sociale medie identiteter som facebook, på trods af privathedsmæssige ulemper. Det handler om at formindske det, der står i vejen mellem dig og det du gerne vil.

    Så hvad kan vi, som designere gøre, når vi bliver nødt til at bede om information fra brugeren? Det allerførste vi kan gøre er at spørge os selv; har vi virkelig brug for den her information – eller er det spørgsmål fra marketing som gerne vil kende køn, højde og antal børn for at bestemme et reklameringssegment? Er det udviklerne, der har brug for information til at identificere brugere? Er der nogen anden måde de kan få den på?

    downloadWroblewski foreslår i sin bog, Web Form Design, at udspørge brugeren om det absolut minimale for at gennemføre brugerens kernemål, og gemme “fluff” spørgsmålene til bagefter når brugeren har større overskud og positiv stemning efter en gennemført transaktion. Research viser faktisk at folk ér mere villige til at udfylde marketing spørgsmål når de først stilles efter formen er udfyldt og godkendt.

    Derudover fremhæver han en anden væsentlig diskussion omkring accessibility; altså at designe hjemmeside og formularer for de mennesker som måske ikke har mulighed for at benytte mus eller keyboard. Det giver nogle interessante udfordringer i forhold til at hjælpe brugeren med at navigere igennem en form, for eksempel udelukkende ved brug af “tab”-tasten. Accessibility er en alvorlig trussel mod informationssamfundet. Efterhånden som stort set alt offentlig interaktion foregår via online formularer er det vigtigt at vi ikke udelukker eller hindrer bestemte samfundsgrupper i at interagere og udfylde digitale formularer på en nem måde.

    Det gode ved bogen er at der er mange eksempler. Det er tydeligt at Wroblewski har meget erfaring inden for feltet og han inkluderer research der underbygger hans råd og påstande.

    Et interessant aspekt jeg fandt i hans forskning var friktionen mellem hvilke designs brugere foretrækker og det design som klarer sig bedst i test i forhold til fejl og udfyldelses-tider. Dette fører mig til den konklusion at nogle gange kan det være en god ide at gå på kompromis med udfyldelsestider hvis et andet design f.eks får brugeren til at føle sig mere sikker, eller får brugeren til at tænke mere over sit input.

    Han præsenterer også begrebet “gradual engagement”, dvs at lade brugerne udfylde småstumper undervejs i interaktionen og så skabe en brugerprofil ud fra det, behind-the-scenes. Det er med til at mindske barrieren mellem brugeren og de krav der stilles fra hjemmesiden/firmaet. Det kan dog også skabe nogle problemer i forhold til at kommunikere for brugeren hvilken tilknytning de har til hjemmesiden og hvor meget information hjemmesiden beholder om dem. Det er kun et lille hjørne i diskussionen omkring automatisk data-indsamling, som ligger uden for scopet af bogen, desværre. Men det er et godt eksempel på at selv igennem udformningen af simple web-formularer har man som designer et etisk ansvar.

    Jeg vil anbefale bogen for enhver som arbejder med webformularer eller som måske er nysgerrig omkring de bagvedliggende elementer og tanker omkring hvorfor webformularer ser ud som de gør. Til tider kan bogen føles lidt lang – især idet hvert kapitel slutter med en liste af “best practices”,  men denne liste gør at bogen egner sig som opslagsværk.
    Denne boganmeldselse er oprindeligt udgivet på engelsk på http://cannonballread.com/2014/05/the-discussion-in-web-form-design/

  • I don’t think the question is whether certain frameworks can or cannot be agile. I rather believe the question should be, given where we are today, In the IT-industry, is the agile mindset still the most beneficial; for companies in general, but certainly also for the people that work there!

  • Exactly; my point is that agile as a mindset just doesn’t work for most people. Some people prefer to work within more fixed structures and we should focus on creating good structures that don’t require constant re-evaluation. Agile, as is today, is mainly a buzzword that at best does nothing and at worst requires constant redefining of methods…[Read more]

  • I think its an interesting distinction between what the users do and what the users want. On the one hand we see an increasing number of users constantly “multi”tasking in ways that would be deems stressors to their systems. On the other hand their is a rising movement of people seeking contemplation and mindfulness; a sense of being present in…[Read more]

  • Everything is a fight for the users attention; not at least from the users themselves. As everything is becoming increasingly mobile, so our way of interacting with technology is being influenced by these new behavioural patterns. People use their cell phones/tablets/etc on the toilet, in waiting rooms or public transit and increasingly while doing other things that were previously regarded as entertainment by themselves; e.g. playing games on the cell phone while watching TV or tweeting from the talks of a conference.

    According to Chris Atherton, a UI-designer with a phD in neuroscience, the user’s attention is finite. Every time the user switches context, e.g. from the t.v. to the phone, it has a cost. Every time a user focuses their attention on one thing, they immediately become less aware of other things; attention is finite.

    As software designers we should take these behavioural patterns seriously. The expectations and habits being formed by the users of these mobile devices follow them into their interactions with supermarket checkout counters, work tools and even other people!

    An easy, practical take away that will work for most types of software design is to assume your user is just tuning in and then evaluate what is the most important thing in her view right now? How much information can they reasonable take in? However it is important not to oversimplify; find out what it is necessary to be able to do and then do that – split it up if you have to.

    Other easy attention-grabbers are color changes and moving objects. They capture attention quickly and sometime subtly. However a lot of things are competing for our user’s attention, including the users themselves.
    Technology as an extension of ourselves
    Atherton also briefly touched upon the amount of outsourcing people do, users are becoming used to relying on technology to ease the cognitive loads. People extend parts of their memory and bodily functions to technology. People expect their technology to help them.

    I would have liked her to touch upon the dualism of technology that she presents here. Some times technology is a voluntary distraction and other times technology is an extension of the person; a person’s technical abilities. The distraction technology should be easily accessable and easily noticeable. The extension technology should be there when we need it. Mobile technology is an excellent source of at-hand distraction technology. And the increasing amount of interaction with these distraction technologies affect how we interact with extension-technologies. We should design for these new interaction patterns, even when desigining serious and critical software – perhaps especially when we’re designing critical software.

    • I think its an interesting distinction between what the users do and what the users want. On the one hand we see an increasing number of users constantly “multi”tasking in ways that would be deems stressors to their systems. On the other hand their is a rising movement of people seeking contemplation and mindfulness; a sense of being present in the moment.

      These two forms of interaction are fluid the same user might prefer different interactions at different times. So how do we, as designers, help manage those seemingly contradictory demands in our software? The discussion quickly becomes normative of how our users ought to live. On the one hand we have the power to design technology with certain features and behaviors, on the other hand users will quickly appropriate and (ab)use the designs any way they like. That’s not to say that we as designers don’t have a responsibility in the products that we create to create something that makes the lives of people better. However, what actually makes people’s lives better is sometimes a big question…sometimes not. But most often the answer is really just; it depends…

      I’m afraid my answer became just a jumble of thoughts as well 😉

  • When the agile manifesto was published it was groundbreaking. It was the sign of an young, rebellious industry. But now the agile movement is 13 years old and well integrated into almost every software company that takes itself seriously.

    So why are people declaring Agile to be dead?
    agile is not Agile.
    The agile manifesto revolves around 4 simple values that have been passed on and pushed into almost every type of software company or enterprise.

    Screen Shot 2014-09-30 at 09.25.05

    Katherine Kirk describes how the goal of the agile is to create a rotational hierarchy, where the most knowledgeable person for a specific task becomes the leader. If a new task arises the most proficient for this type of problem takes the role as leader. However this rotational hierarchy inevitably ends up butting heads with the static structures of management, labelled universally and across the board as psychopaths by Kirk (who displays a lack of the empathy and compassion that she later works so hard in advocating).

    She, if any, works hard on establishing the “us” and “them”, where the developers are labelled as the heroical introverts cruelly held down by the management with their inevitable psychopathic tendencies.

    However, as became evident in the stories told by Corry and Richter people, not just management, inevitable converge into processes, whether they are deemed traditionally agile or not.

    Again and again it is postulated that agility is NOT a fixed set of methods it’s a state of mind. It’s a willingness to constantly be open to and explore the methods and work patterns that work optimally for this specific development team and for this specific task. However, the agile movement has become Agile – a buzzword that is thrown around and not an actual mindset.
    Focus on the process
    What becomes clear from talk after talk about how to employ the agile mindset is that most people respond to, and end up in, fixed structures and processes. Processes were they lean on the agile tools, like scrum which at its worst is useless, but at least not harmful.

    I think the software industry needs to be brave and realize; maybe we shouldn’t be agile. Rather we should accept that people need a certain element of predictability and stability. An element that should be found in processes.

    We should focus on the construction of processes rather than the abolishment. However that requires a new mindset; that maybe not all static processes are evil, maybe a certain sense of stability can actually lead to more exploration and risk-tasking. Some people are not interested in constantly re-evaluating and redefining the minutiae of processes every month, but would rather focus on work. A stable process would give them the flexibility to do that.

    The agile manifesto has revolutionised the software industry, but it has turned into the rigidity is was trying to deflect. We have blindly followed the values of other’s when the point was to create our own. It’s time to do something new. It’s time to proudly declare; I am not Agile!

    • Noooooh…. Please don’t confuse agile with the methodoligies. I also noticed how KKirk pushed roles and relationship into agile.

      Agile is a mindset or a set of values. It does not tell you to take on specific roles.

      Scrum is a set of roles, artefacts and ceremonies all designed to adhere to the agile manifesto. However, not all implementations can be considered agile.

      In fact, some of the most agile teams I know are not using Scrum and certainly not Kanban. In their words: they use comon sense.

    • Exactly; my point is that agile as a mindset just doesn’t work for most people. Some people prefer to work within more fixed structures and we should focus on creating good structures that don’t require constant re-evaluation. Agile, as is today, is mainly a buzzword that at best does nothing and at worst requires constant redefining of methods and processes.

      So many industries flourish just fine without agile – maybe the tech industry could too?

    • Still a ‘noooooohhhh’ from my chair.

      People can be agile even if they use wafterfall or similar structured processes.

      The key is to bring people together to build software – togehter.

      Scrum, at its purest, also enforces hiearchy. Not in the scrum team but f.i. towards the Product Owner.

      • I disagree that people can be agile if they use the ‘waterfall’ model. The mantras have been that you cannot do agile, if the whole company/organisation isn’t agile
        (e.g. if the main process is waterfall and the mindset of the bosses etc. is waterfall).

        You can of course try to apply agile when using waterfall as the main strategy for development, but it is very difficult and I’m not sure you will succeed – even after many years. I have seen, tried and experienced this for 7-8 years (in a company that was using waterfall).

        • Sooo…. having this mindset:

          Individuals and interactions over processes and tools
          Working software over comprehensive documentation
          Customer collaboration over contract negotiation
          Responding to change over following a plan

          … is impossible when doing something else than Scrum, Kanban, etc.? I concur.

          It is true that Scrum, Kanban, etc. have been invented to “implement” the mindset, but the mindset certainly also applies to other frameworks.

          • I don’t think the question is whether certain frameworks can or cannot be agile. I rather believe the question should be, given where we are today, In the IT-industry, is the agile mindset still the most beneficial; for companies in general, but certainly also for the people that work there!

  • There are opportunities for networking in many areas of life, but none so more that a good ol’ fashioned conference. People from all over the industry gather together diving into toughest problem areas and […]

    • Great article! It’s always good to keep in mind not to ask questions that can be answered with yes or no, because then you’re back at your starting point. If you’re not good at coming up with questions that could lead to interesting answers then try using this list of 365 table topics I came across in my own preparation for the GOTO conference coming up: http://www.dist8tm.org/docs/TM-%20365%20Sample%20Table%20Topics%20Questions.pdf
      They aren’t all equally suitable, but sometimes you get more interesting conversations if you ask questions that aren’t expected 🙂

  • I de fleste IT-virksomheder skal man blot kigge sig omkring for at se at der er underskud af kvinder – og nu er vi nogen der har sat os for at gøre noget ved det. Derfor afholder vi igen i år IT-camp for piger mellem 16-19 år. De kan kan troppe op på Aarhus Universitet i tre dage og blive præsenteret for alle facetter af IT og computere. Og det er endda helt gratis! Vi har som arrangører været heldlige at møde stor opbakning og blive sponsoreret af mange virksomheder, som ser det samme problem som vi gør; det er svært at få kvinderne ind på IT-branchens snævre korridorer. Vi mener løsningen er at tænde gnisten hos de unge kvinder; vise dem hvad de kan med IT. Og det er netop det vi gør på vores camp under temaet: Helpful technology.
    Helpful Technology
    Vi oplever, at mange piger har fordomme om it-branchen og ikke betragter det som en mulig karrierevej; den opleves som nørdet, kikset og forbeholdt den stereotype mandenørd. Vi ser det som en vigtig opgave, at mangfoldigheden inden for IT-branchen synliggøres både indadtil og udadtil. Vi har valgt et tema, der kan appellere bredt og som giver mulighed for diversitet og kreative input. Vi giver plads til de piger med flair for sociale problemstillinger OG de piger som tænder på teknologi og hardcore kode. Pigerne vil komme til at arbejde projektorienteret inden for en bestemt case. Casen vil blive belyst via forelæsninger, workshops, virksomhedsbesøg og møde med forskellige rollemodeller fra både studier og virksomheder. Dermed ønsker vi at give pigerne en fornemmelse for arbejdsformen både på universitetet og i industrien; hvor det i høj grad handler om tværfagligt samarbejde for at løse problemstillinger.

    Mange piger har et ønske om at forandre verden til det bedre og det er vores håb at vise at IT er den mest direkte (og sjove!) vej til resultater. Gennem campen fører vi pigerne igennem en mini-process som viser dem hvordan man kan bruge IT til at realisere sine ideer og skabe konkrete produkter og løsninger.

    RED VERDEN – Med IT!
    Som jeg har diskuteret andre steder, så kan kvinder tit bidrage med andre synspunkter når de træder ind i en mandsdomineret branche. Der er stadig masse uudforsket potentiale for hvad IT kan udrette. Så hjælp os med at introducere unge kvinder mellem for IT så vi kan få nye perspektiver og – måske – redde verden. Man kan læse mere om IT-camp og tilmelde sig på http://www.itcamp.dk

  • Mathilde Hoeg commented on the post, Bliv IT-rollemodel, on the site Helena Meyer 4 years ago

    Hej Mikkel,

    Det ér svært at vælge uddannelse. Det kan føles som en meget stor beslutning, især hvis man ikke helt føler man ved hvem man er og hvad man lige er til. Men spring bare ud i det! Om du er teoretisk eller praktisk orienteret finder du nok så småt ud af hen af vejen og der er især datalogi nem at tilpasse; enten at dykke ned i et nør…[Read more]

  • Fejlbeskeder har potentiale til at forandre måden vi bruger computeren på. Alle oplever dem, mange hader dem; de er forvirrende, frustrerende, blokerende. Der er kommet en trend i at undgå dem som en del af at sikre brugervenligt design. Dette fører ofte til snørklede begrænsninger af input uden yderligere forklaring eller instruktioner, hvor alle tænkelige hændelser er møjsommeligt udspecificeret. Som om blot det at undgå fejlbeskeder medfører at ingen laver fejl.
    Have-grave-redskaber

    Twitter kommunikerer klart at brugeren ikke er skyld i, eller kan rette op på fejlen.

    Twitter kommunikerer klart at brugeren ikke er skyld i, eller kan rette op på fejlen.

    Det er godt at være specifik i sine instruktioner, men nogle systemer er mere komplekse end andre. Står der en instruktion, der er så specifik at den nærmer sig roman længde, så springer læseren over. Ofte behøver det ikke være mere end et par linier – mange læsere navigerer igenem internet-former på andre visuelle “cues” end lige netop de tekstuele forklaringer.

    I stedet for at undlade fejlbeskeder bør man i stedet fokusere på at formidle den præcise fejl så godt som muligt. Har brugeren indtastet for mange, eller ikke-tilladte tegn så skal de have det at vide så de kan rette det. Er det en systemfejl, som brugeren ikke kan rette? I så fald skal brugeren vide det.

    Vi kan sagtens lave semantiske krumspring ala Don Norman og kræve at det skal hedde noget andet end fejlbeskeder, men det virker som en unødvendig eufemisme for noget, der sker og sker ofte. Hvis jeg hamrer mig selv over fingeren med en hammer, så er det jo ikke hammeren som er dårlig designet, men mig, der er et uopmærksomt fjumrehoved – det er mig, der har lavet en fejl. Lad os undlade at kalde en spade for et have-grave-redskab, når det er en spade.
    Fejlbeskeder er kommunikation
    Det der er nødvendigt at bemærke er jo at disse situationer ikke opstår mellem et menneske og en computer. I virkeligheden er det en kommunikation mellem det menneske, som bruger systemet og de, der har designet og programmeret det. Derfor vil der opstå fejl i computersystemer eller software; hvadenten manglerne opstår på grund af programmørens begrænsninger eller brugerens manglende forståelse og/eller investering.

    Fejlbeskeder giver netop brugeren agens. Computer er et udbredt redskab og fejlbeskeder gør computeren til et gennemsigtigt redskab for den almene bruger; så de kan tage stilling, lære, reflektere og ja, fikse deres fejl.

    I stedet for at se fejlbeskeder som irriterende stopklodser, i stedet for at fokusere på at skabe fejlfri systemer der reducerer brugerne til dataindtastere, bør vi i stedet se fejlbeskeder som mulighed for kommunikation mellem designer og bruger. Feedbacken sikrer et samarbejde mellem bruger og programmør om bedst muligt at få udført opgaven – for alle parter.

  • ThumbnailScientific investigations of fashion choices in the tech community are few and far between. As part of my coverage of GOTO last year I set out to discover…what exactly do computer scientists wear? The results […]

  • “Undskyld har du oprettet digital post?” En kommunedame har allerede stukket flyeren halvvejs i hånden.

    Jeg afslår høfligt med et “Jeg har ikke internet”

    “Jamen så kan du ikke få post fra det offentlige!” […]

  • Load More