• Explore

  • What's in my bag

    What's in my bag

Bio text

Abby's leather tote bag
Abby's minibag bag charm
Abby's brown bag charm

Minor nerds & reflections

  • Stop using JS for that - Kilian Valkhof

    • 🔗 Electron governance, application to build desktop apps with html, css and js
    • 🔗 Polypane browser, browser created for developers with accessibility functions and

    🪐 Moving features from JS to CSS & HTML

    The rule of least power = altijd de minst krachtige taal kiezen zodat browser alle slimme keuzes kan maken(voor betere experience, meer error controle)

    🤎 Custom switches

    Door Input in label weet browser dat label/text erbij hoort en maakt deze ook klikbaar

    Reflectie

    Over het algemeen vond ik Kilian's talk denk ik één van de nuttigste. Daarmee bedoel ik dat hij hele handige technieken heeft laten zien die ik tijdens de minor heb gebruikt en nog veel vaker ga toepassen in de toekomst. Daarbij heeft hij the rule of least power geïntroduceerd. Iets waar steeds meer rekening mee wordt gehouden en een codeertechniek die mij erg aanspreekt, gezien ik niet zo van JS houd. Dit is dan ook mijn 'nieuwe' uitgangspunt developer.

  • Typography - Roel Nieskens

  • Beyond tweening - Cassie Evens

  • Uitkomst van de Hackaton(les voor mij)

    Wat ik voor mezelf vooral uit de weekly nerd heb gehaald is dat, waar ik tijdens deze minor vaak denk dat mijn ambitieuze ideeën een valkuil zijn, dit het eigenlijk helemaal niet is. Het is zo dat ik vaak ideeën qua concept en functionaliteit heb, die tijdens het werken(coderen) van de opdracht veel moeilijker en ambitieuzer zijn dan dat ik weet en technisch vaak ook erg uitdagend om te realiseren. Dit zorgt er vaak voor dat opdrachten lang duren en misschien niet heel erg compleet zijn bijvoorbeeld. Zelf denk ik dat dit vanuit mijn design

    Tijdens de hackaton hadden we als groep(naar mijn idee) een beetje moeite met een passend en gaaf concept te bedenken die women in tech echt uitlichtte. Ik heb toen geopperd iets geks of onconventioneels visueel te doen, ondanks dat we niet zo goed wisten hoe we hier dan de nieuwe technieken in gingen toepassen. Toen ik hier een beetje terughoudendheid in merkte ben ik meegegaan in het ‘veilige’ concept. Maar hierdoor eindigde het project ook eigenlijk in een saai en veilig concept/website waarbij ik naar mijn idee technisch niet veel nieuws heb geleerd.

    In tegenstelling dus tot wanneer ik juist het ambitieuze en onzekere concept kies, waarbij ik geen idee heb of het technisch mogelijk is. Waarbij ik eigenlijk altijd juist uiteindelijk heel veel leer. Ik krijg dus eigenlijk altijd de vraag moet je dat wel doen, of gaat dat wel lukken? Geen idee, maar ja, ik ga het wel doen want ik leer er heel veel van en het is helemaal geen slechte eigenschap altijd de moeilijke weg te kiezen.

  • Mijn doelen

    Mijn vorige leerdoelen

    1. 1. CSS animeren, transities & interaction
    2. 2. Beter begrip van websites
    3. 3. Mijn eigen meer professionele manier van coderen ontwikkelen
    4. 4. Meer out of the box en vette, expressieve functies ontwikkelen(meer speels, interactie, laten nadenken en websites meer fun en persoonlijk maken)(brutalists websites)
    5. 5. Design visie meer ontwikkelen en doorvoeren, ook in code

    Als eerste leerdoelen had ik veel leerdoelen met specifieke doelen, zoals het toepassen van CSS animaties en een beter begrip krijgen van websites. Uiteindelijk heb ik eigenlijk al mijn leerdoelen gehaald of er in ieder geval genoeg aan gedaan/begonnen om ze gehaald te hebben. Zo zal het doel ‘Mijn eigen meer professionele manier van coderen ontwikkelen’ een ongoing proces zijn.

    Drie persoonlijke leerdoelen voor meesterproef

    1. 1. Alles leren over er komt kijken bij goed en efficient samenwerken met coderen. (Waar moet je op letten? Hoe verdeel je de taken/wie doet wat? Werken met gitHub)

      Ik ben tevreden als ik een duidelijk beeld heb van samenwerken met coderen en punten heb waar ik/we in de toekomst op moeten letten.

    2. 2. Mijn ‘handelsmerk’ vinden en toepassen, sluit aan op ‘mijn eigen meer professionele manier van coderen ontwikkelen’ maar dan wat mijn codeerprojecten kenmerken ontdekken/onderzoeken(zowel visueel als UX en interactie en technieken)

      Ik ben tevreden als ik duidelijk heb voor mezelf wat mij als developer onderscheid van anderen en wat mijn 'niche' is, plus als ik specifieke codeertechnieken vind/gebruik die ik eigen maak of in de toekomst vaker verwacht toe te passen in mijn codeerprojecten.

    3. 3. Meer denken aan de gebruikerservaring, verder dan alleen flow(wat vaak al als erg prettig wordt ervaren in mij werk) met progressive enhancement en accessibility (Prefers reduced motion etc.) Meer denken aan de gebruikers voorkeuren

      Ik ben tevreden als ik heb geconceptualiseerd over functionaliteiten die de gebruikerservaring verbeteren al dan niet leuker maken voor een specifieke doelgroep, ik mij met accessibility richtlijnen in code bezig heb gehouden en specifiek technische codeertechnieken/methoden heb uitgevoerd. Denk aan coderen voor screenreaders, tab navigatie, responsiveness in personalisatie(dark/light mode en andere gebruikersvoorkeuren) en browser tech of reduced motion.

  • Als eerste leerdoelen had ik veel leerdoelen met specifieke doelen, zoals het toepassen van CSS animaties en een beter begrip krijgen van websites. Uiteindelijk heb ik eigenlijk al mijn leerdoelen gehaald of er in ieder geval genoeg aan gedaan/begonnen om ze gehaald te hebben. Zo zal het doel ‘Mijn eigen meer professionele manier van coderen ontwikkelen’ een ongoing proces zijn.

  • Reflectie meesterproef

    Over het algemeen denk ik dat de meesterproef erg goed is gegaan ondanks dat we veel moeite hadden om tot een definitief concept te komen. Omdat de samenwerking goed ging, we naar elkaar luisterden en we het persoonlijk met elkaar konden vinden, zijn we uiteindelijk tot een duidelijk en af concept gekomen. Als dit niet het geval was, durf ik niet te zeggen of dit gelukt zou zijn.

    Wat ging goed/viel mee?

    • We stelden elkaar continu veel vragen en vroegen om bevestiging, hierdoor zaten we grotendeels altijd op één lijn.

    • We hielpen elkaar goed wanneer iemand hulp nodig had of biedde dit vanuit onszelf al aan wanneer iemand moeite had.

    • Ondanks dat de opdrachtgever aan het begin niet helemaal tevreden was, ging de communicatie en de verwachtingen die hij van ons had goed en hebben we denk ik geleverd wat hij van ons verwachtte.

    Wat ging minder/wat viel tegen?

    • Aan het begin liet Cas ons erg vrij in wat hij wilde en van ons verwachtte, zolang we het maar konden onderbouwen. Dit gaf ons erg veel vrijheid en het ook moeilijker om iets te bedenken waar hij tevreden mee zou zijn. Door te beginnen met onderzoeken, veel ideeën te schetsen en

    • Ook hadden we pas veel later toegang tot de data dan verwacht en was deze eigenlijk niet optimaal en inconsistent om te gebruiken, zo leverde dit veel vertraging voor ons op en komen veel accessibility problemen door deze data zelf en hebben wij dit niet op kunnen lossen

    • Het komen tot een concreet concept was moeilijk, ik denk vooral omdat we continu veel verschillende feedback kregen van verschillende mensen. Dit sprak elkaar vaak tegen en hierdoor wisten we vaak niet zo goed wat we ermee aan moesten.

    Persoonlijke leerdoelen

    1. 1. Alles leren over er komt kijken bij goed en efficient samenwerken met coderen. (Waar moet je op letten? Hoe verdeel je de taken/wie doet wat? Werken met gitHub) Ik ben tevreden als ik een duidelijk beeld heb van samenwerken met coderen en punten heb waar ik/we in de toekomst op moeten letten.

      Ik heb dit leerdoel gehaald, omdat ik veel lessen heb gehaald uit het samenwerken en een goed beeld heb voor in de toekomst waar ik op moet letten als in nog een keer ga samenwerken aan codeerprojecten. Notabene heb ik hier een lijst van gemaakt:

      Things I learned with working on group code projects * One person takes notes and documents general process * Don’t be afraid to ask (critical) questions and be clear in want you need and expect from opdrachtgever * One person for contact * One or two people to inspect data (access, content, relations, retrieval and endpoints) * General structure of folders with naming, read me and wiki * Wireframes are not only important to use for the flow, but also to experiment and get everyone on one line. As well as show client what to expect * Take client through your process * Clients generally don’t really know what they want or need to see, tell them what to expect next time and what you’ll show * Één persoon aanstellen als notulist, die aantekeningen maakt bij meetings en feedback —> zo gaat het proces niet verloren en ontstaat er later geen verwarring * Testplan laten opstellen door één persoon die hier goed in is en daarna met iedereen doorheen gaan, kijken wat belangrijk is (wat echt verteld/uitgelegd moet worden aan testpersoon), waar je antwoorden op/duidelijkheid over wilt uit het testen (welke vragen moeten er nog bij) en hoe je het gaat documenteren * Beginnen met alle branches aanmaken voor de pagina’s en features plus de components ervoor * Algemene namen voor pagina’s en functies bespreken om later verwarring en vele aanpassingen te voorkomen * Iedereen heeft een andere manier van coderen, ondanks dat je code conventies opstelt, blijft het verschil groot en voor anderen soms onlogisch * Feedback geven op elkaars code is moeilijk, maar wel erg belangrijk om code begrijpelijk en makkelijk aanpasbaar te houden —> miss goed om na een eerste prototype elkaars code te bekijken en feedback te geven, om later veel of grote aanpassingen te voorkomen * Één persoon aanstellen om WCAG richtlijnen te onderzoeken en te handhaven in eigen code * Het concept dat je bedenkt/uitwerkt is volledig afhankelijk van de content/data die beschikbaar is, deze moeten op elkaar aangepast worden, dan wel voor elkaar gemaakt worden * Van te voren afspreken welke styling in welk bestand moet, base, alle base css over de hele website als headings en tekst

    2. 2. Mijn ‘handelsmerk’ vinden en toepassen, sluit aan op ‘mijn eigen meer professionele manier van coderen ontwikkelen’ maar dan wat mijn codeerprojecten kenmerken ontdekken/onderzoeken(zowel visueel als UX en interactie en technieken) Ik ben tevreden als ik duidelijk heb voor mezelf wat mij als developer onderscheid van anderen en wat mijn 'niche' is, plus als ik specifieke codeertechnieken vind/gebruik die ik eigen maak of in de toekomst vaker verwacht toe te passen in mijn codeerprojecten.

      Ik heb dit leerdoel gehaald, omdat ik tijdens het samenwerken wel echt bevestiging heb gekregen van waar mijn sterke punten liggen binnen coderen. En dat is UX in de flow en code van een website, overzicht houden, consistente code waarborgen, semantisch coderen en zoveel mogelijk the rule of least power gebruiken(bijna geen JS gebruikt). Ook heb ik technieken/methoden al meer eigen gemaakt, zoals het gebruiken van details en summary voor het switchen tussen content en veel flexbox.

    3. 3. Meer denken aan de gebruikerservaring, verder dan alleen flow(wat vaak al als erg prettig wordt ervaren in mij werk) met progressive enhancement en accessibility (Prefers reduced motion etc.) Meer denken aan de gebruikers voorkeuren Ik ben tevreden als ik heb geconceptualiseerd over functionaliteiten die de gebruikerservaring verbeteren al dan niet leuker maken voor een specifieke doelgroep, ik mij met accessibility richtlijnen in code bezig heb gehouden en specifiek technische codeertechnieken/methoden heb uitgevoerd. Denk aan coderen voor screenreaders, tab navigatie, responsiveness in personalisatie(dark/light mode en andere gebruikersvoorkeuren) en browser tech of reduced motion.

      Ik heb dit gehaald, omdat ik geconceptualiseerd heb over functionaliteiten die de gebruikerservaring verbeteren, zoals het switchen tussen content met details en summary, maar ook het gebruik van de prefers reduced motion media query. Ook heb ik mij bezig gehouden met accessibility richtlijnen in code, zoals het toegankelijk maken van svg's voor screenreaders en het verbeteren van de headings van Framer Framed. Ik heb hiervoor ook de data en de uitkomst van het WCAG onderzoek van FF onderzocht.

    Highlights weekly nerds

    De gootste highlight van de weekly nerds was voor mij toch wel CSS day, waar ik een dag naartoe ben geweest. Door alle gave projecten van de pro's te zien weet ik zeker dat ik development en coderen echt mee wil gaan nemen in mijn loopbaan voor de toekomst, samen met design. De grootste les die ik uit alle weekly nerds heb gehaald is dat je vooral moet doen wat je leuk vind en waar je goed in bent en dat je dan altijd succesvol zal worden op een manier!