====== Portflow ======

> **Samenvatting**
>//Deze pagina beschrijft de didactische visie achter het gebruik van Portflow en geeft een duidelijke en hanteerbare MinMax aanpak voor de implementatie ervan.//

===== Wat is Portflow? =====
Portflow is een plug-in voor een LMS, zoals bijvoorbeeld [[..:beleid:canvas|Canvas]]. In Portflow kunnen studenten de voortgang in hun ontwikkeling zichtbaar maken en onder eigen beheer verantwoorden door bewijs te verzamelen, feedback te vragen aan docenten, medestudenten en experts en een beoordelingsdossier aan te maken. Docenten kunnen studenten in dit proces de nodige ondersteuning bieden (Bron: [[https://drieam.com/en/solutions/portflow/|Drieam]]).

===== MinMax =====

Om studenten te faciliteren bij het gebruik van de onderstaande [[..:beleid:canvas#3. MinMax functionaliteit|MinMax-implementatie]], kan er een Portflow-sjabloon worden gemaakt. Een sjabloon dat enkele van de functies implementeert, is hier te vinden: 

<//Link naar Portfolio-sjabloon volgt binnenkort//> [Red.]

==== Voorpagina ====

Op de 'voorpagina' van het portfolio staat een beschrijving van de persoon zelf, zoals weergegeven in Figuur 1. Het idee is dat deze beschrijving continu wordt aangepast om aan te sluiten bij de huidige situatie. 

**Figuur 1**\\
//Screenshot van een Portflow-voorpagina//.

{{:beleidsvoorbereiding:homepage.png?600|}}

De beschrijving bevat de volgende onderdelen:

  * Persoonlijke informatie, inclusief zaken zoals:
    * Wie ben ik - een persoonlijke beschrijving van wie je bent en wat je drijft.
    * Wat heb ik in het verleden gedaan/wat is mijn expertise?
    * Motivatie - beschrijving van wat je motiveerde (en wat niet).
  * Wat wil ik leren / wat voor soort professional wil ik in de toekomst zijn?
  * Optioneel een opsomming van wat de lezer kan verwachten in de verschillende secties. Dit is vooral belangrijk als secties niet (alleen) per semester zijn georganiseerd.

==== Secties ====

Een sectie is een onderdeel dat een logisch afgebakende onderwijseenheid omvat met een beschrijvende titel of een aparte activiteit die niet aan het curriculum is gebonden (bijvoorbeeld deelname aan een robotica-COP, activiteiten vanuit een bestuursrol, etc.). In Figuur 2 is een aantal secties weergegeven. 

**Figuur 2**\\
//Screenshot van een aantal secties binnen Portflow//.

{{:beleidsvoorbereiding:sections.png?600|}}

'Collecties' per logisch samenhangende bewijsstukken binnen het semester. Deze kunnen onder andere omvatten:

  * Een collection voor het gehele semester
    * Pro: geeft de student een gemakkelijk, holistisch overzicht van de voortgang van leerdoelen.
  * De verschillende projecten die binnen dit onderdeel zijn uitgevoerd:
    * Een groepsproject - Groepsuitdaging <projectnaam>
    * Een individueel project - Individuele uitdaging <projectnaam>
    * Pro: heldere relatie tussen de context en de bewijsstukken voor de coach.
  * Diverse gebundelde resultaten rondom een thema binnen dit onderdeel
    * Het resultaat van één of meer opdrachten
    * Het resultaat van een projectcasus over dit thema
    * Pro: sluit aan bij onderwijseenheden die bestaan uit meer kleinere, niet-samenhangende thema's.
  * Overig bewijsmateriaal - bewijs gerelateerd aan het semester, zoals een semesterevaluatie of reflectie, relevante buitenschoolse activiteiten zoals deelname aan seminars of hackathons, enz.

**Bad practice:**\\
Een collection zoals deze mag NIET worden gebruikt voor het bundelen van doelen voor professionele ontwikkeling, aangezien vanuit didactisch oogpunt bewijsmateriaal gecreëerd dient te worden in de context van een van de andere collections.

==== Collection ====

Binnen Portflow kunnen verzamelingen worden aangemaakt, collections genoemd, zoals weergegeven in Figuur 3.

**Figuur 3**\\
//Screenshot van een Portflow-collectie//.

{{:beleidsvoorbereiding:collection.png?600|}}

Per verzameling:

  * Titel (zoals een projectnaam 'groepsproject Growthmoves', of onderwerp 'Generatieve AI')
  * Een compacte beschrijving van wat er in deze verzameling te vinden is (bijvoorbeeld een algemene beschrijving van het project of van een onderwerp)
  * Een beschrijving van de verzameling met een leeswijzer. De leeswijzer zorgt ervoor dat de relatie tussen de verschillende bewijsstukken duidelijk wordt voor de lezer. Het verwijst ook op een eenvoudige manier naar deze specifieke bewijsstukken via @verwijzingen.
  * De bewijsstukken zelf, bij voorkeur gelinkt aan de 'doelen' binnen deze verzameling.

**Good practice:**\\
De leeswijzer kan bijvoorbeeld chronologisch gestructureerd worden door per sprint te beschrijven welke professionele producten/bewijzen zijn voortgekomen.

**Bad practice:**\\
Het gebruik van een verzameling per leerdoel.

==== Goals ====

Om de voortgang van doelen te kunnen volgen, stelt Portflow gebruikers in staat persoonlijke leerdoelen te stellen. Ook kunnen doelen worden opgenomen in Portflow-sjablonen. Gebruik de leerresultaten van je semester als leerdoelen in Portflow. Zie Figuur 4.

**Figuur 4**\\
//Tabel met een aantal leerdoelen (Goals) binnen Portflow//.

{{:beleidsvoorbereiding:goals.png?600|}}

**Good practice**\\
In sommige semesters worden de leerdoelen zeer nauwkeurig gedefinieerd in lijn met het HBO-i competentie model. Daar bestaan de leerdoelen uit de competenties (Analyse, Advies, ...) en professionele vaardigheden.

==== Evidence ====

In deze verzameling ga je bewijsstukken toevoegen. Zorg ervoor dat je de bewijsstukken zodanig bundelt dat de granulariteit passend is. Dat wil zeggen: je lezer wordt niet overladen met kleine bewijsstukken die op zichzelf weinig relevant zijn. Aan de andere kant is één groot document met 'alles erin' ook niet wenselijk. Idealiter streef je naar 2 of 3 bewijsstukken per sprint of iteratie. Deze moeten relevante werkproducten zijn, zoals een document voor softwarevereisten, een ontwerp voor gebruikersinteractie (met alle schetsen en ontwerpiteraties geïntegreerd), een testplan voor hardware en een rapport van de resultaten, etc.

Als het bewijsstuk een groepsproduct is, maak dan ook duidelijk wat jouw bijdrage aan dit bewijsstuk is.

**Good practice - tussenstappen en producten:**\\
In bepaalde semesters zijn de soorten bewijsstukken die zijn toegestaan, beperkt. Je mag bijvoorbeeld alleen inleveren:

  * Stepping stones:
    * Individuele kleinere bewijsstukken.
  * Professionele producten:
    * Grotere bewijsstukken die (een significant deel van) een of meer onderzoeksvragen beantwoorden. Dit kan een groepsinspanning zijn.

**Good practice - ‘essentiële vragen’:**\\
Om het proces transparant te maken, gebruik bij de beschrijving van het bewijs de ‘essentiële vragen’ (devlog-stijl) in de beschrijving:

  * Welk probleem (uitdaging) los ik op bij het werken aan dit bewijsstuk?
  * Waarom is dit een relevant probleem?
  * Hoe zal ik dit oplossen, of heb ik het opgelost?
    * Gebruik het [[..:beleid:dot_framework|DOT Framework]]
    * Onderzoeksmethoden
  * Wat is de kwaliteit van het resultaat?
  * Hoe heb je de kwaliteit gevalideerd?
  * Wat is de volgende stap nu ik dit resultaat heb?

==== Canvas en Portflow ====

Beroepsproducten worden door studenten gedurende het semester verzameld in Portflow. Feedback op producten kan worden gevraagd op verzoek van de student en kan worden vastgelegd in Portflow. Taakgerichte feedback kan landen bij het commentarenveld van het betreffende product of de betreffende collectie als deze op een holistisch niveau zit.

=== Canvas-assignments, rubrics en beoordeling ===

Op regelmatige basis (bijvoorbeeld een vast aantal keer per semester of op het eind van iedere sprint) wordt op mijlpaal-momenten een snapshot van het portfolio gemaakt en ingeleverd in een Canvas-assignment. Deze assignment is voorzien van een rubric waarin de beoordeling op competentieniveau of leeruitkomst vastgelegd wordt. Bij een vaste set aan potentiële competenties of leeruitkomsten kan deze rubric handmatig worden gemaakt.\\ 

Bij situaties waarbij de competenties flexibel zijn (bijvoorbeeld zoals bij Open Learning), is dit lastiger omdat de rubric met potentiële competenties erg groot kan zijn. In dit geval, kan gebruik worden gemaakt van de tooling zoals gebruikt bij OvP (ontwikkeld door Dennis Cools). Deze tooling maakt het mogelijk op een gebruiksvriendelijke manier een beoordeling in te voeren en deze te vertalen naar een ingevulde rubric.  

Naast de ingevulde rubric wordt een mijlpaal-oplevering ook voorzien van een stukje toelichting hoe deze beoordeling tot stand is gekomen.

{{tag>Informatiesystemen Toetsing}}