Tag Archives: blackboard

Patent-Infringement-Avoidability

Ja, trottoir is ook een moeilijk woord, alleen dat is in het Frans. Dus bij deze een andere, maar dan in het Engels… Waarom?

Ik had een redelijk primaire reactie na het lezen van deze. Gelukkig is wordpress ook weer niet zo laagdrempelig dat die reactie 1-op-1 op je blog komt 😉 Anyway, Blackboard gaat weer achter een patent aan. Even disclaimer:

  • Ik ga er van uit dat er allerlei redenen zijn waarom een leverancier, buiten zijn eigen wil om, in een patenten-oorlog verzeild raakt.
  • Ik ga er van uit dat Amerikaanse situaties i.v.m. patenten verschillen van Europese.
  • Ik ga er vanuit dat zo’n patenten-oorlog als klant te ingewikkeld is om echt te volgen. Voor wie dat wil ervaren: lees Michael zijn feed van Edupatents maar eens door.
  • Ik ga er van uit dat een klant niet eens wil weten hoe die patenten in elkaar steken. Als klant wil je er vooral geen last van hebben. Bijvoorbeeld door verminderde investeringen in innovatie, die zijn weerslag krijgen in een applicatie die trager ontwikkelt.

Maar even verder redenerend: hoe kan een edupatent nadelig werken voor het onderwijs?

  • Ontwikkeling: juridische processen zijn kostbaar, waardoor minder geld overblijft voor de ontwikkeling van het pakket. Dus in plaats van geld te besteden aan innovatie, wordt er geld besteed aan advocaten en juristen.
  • Licentie-kosten: een leverancier moet het geld ergens vandaan halen. Dat leidt indirect tot afwenteling op de klant door hogere licentiekosten. Waar een onderwijsinstelling weer voor opdraait.
  • Verminderde functionaliteit door patent-inbreuk, als deze functionaliteit echt uit de applicatie gesloopt moet worden.

Of een leverancier zijn geld, tijd en energie niet steekt in zinloze patent rechtszaken, kun je geen onderdeel maken van de functionele eisen van een software pakket. Als je nog bezig met de keus er van of zo. Of als je onderzoek doet of je het huidige pakket niet eens wil migreren naar een ander… Ten minste, niet direct: als een patent zou leiden tot afwezigheid van functionaliteit, dan zou het gemis ervan gewogen kunnen worden, t.o.v. je eisen.

Hoe kun je dit dan wel meenemen in pakketkeuze?

Ten eerste zou er een nieuw soort eis geformuleerd kunnen worden, maar dan onder het hoofdstuk “Non-functional-Requirements“. Wikipedia geeft een hoop voorbeelden, waaronder “Legal and licensing issues”. Meer specifiek zou dit dan kunnen heten: “Patent-Infringement-Avoidability” oftwel het vermogen patent-inbreuken te vermijden.

Ten tweede zou je hier indicatoren voor kunnen verzinnen, die antwoord geven op de vragen:

  • Hoe groot is de kans dat deze leverancier betrokken raakt bij patent conflicten?
  • Hoe zou deze leverancier zich gedragen als het conflict niet vermeden kan worden?
  • Wat zou hij dan doen om negatieve gevolgen voor de klant te vermijden?

Het kunnen scoren van de antwoorden op deze vragen lijkt me wel moeilijker en het werk van analysten en marktkenners. Iemand een idee?

SMS via je ELO

Ik kreeg vandaag een telefoontje van een SMS leverancier. Of we interesse hebben in SMS-en vanuit de ELO. In het verleden hebben we dit alles bekeken om zo mededelingen of nieuwe cijfers te sms-en. Maar ik vind het niks (meer). Soms merk je dat de werkelijkheid alles inhaalt.

Mijn eerste reactie was: “boven de 10 cent per sms is praten we niet eens”. Toen bleek het 11 cent te zijn….
Ik heb de beleving dat Telecom carriers zelf 3 cent per sms kwijt zijn…
Maar afgezien van geld, we zijn er al eerder mee bezig geweest:

  • Er zijn verschillende sms building blocks die opzich niets kosten, je betaalt alleen per sms.
  • We hebben rond de tafel gezeten met een beginnend bedrijfje, die zelf afhaakten omdat “sms toch gaat verdwijnen en mobiel internet steeds meer toeneemt”.
  • We zijn al een tijd op zoek naar een mogelijkheid om dagroostering goed te communiceren. In onze leerfabrieken is het niet meer te doen om met papier rond te rennen en deze op te hangen op 4 plekken in elk gebouw.
    Maar: geen communicatie==>geen dagroostering==>geen goede aanwezigheidsregistratie==>veel $%^@# met accountant.

Mijn 2 kwartjes:
Als er vanuit het onderwijsproces behoefte bestaat om laagdrempelig, anytime, anywhere, mobiel berichten door te geven, dan zouden we de mogelijkheid kunnen onderzoeken, maar ik vind het een echte 2005 oplossing. Had toen leuk geweest, maar geef het nog een jaar en de mobiele breedband beschikbaarheid onder studenten is nog hoger. Of ben ik te optimistisch?
Of liever gezegd: mededelingen van 140 karakters zullen wel blijven bestaan, maar dan via http ipv sms.

Daarnaast: stel dat 100 courses in onze Blackboard omgeving 1 sms per week genereren, gedurende een jaar van 38 weken, aan 1000 studenten. Dan levert dat 100x38x1000=3.800.000 sms-jes op, of grofweg 400.000 euro.
Dat zou dan zijn als er 1 mededeling ge-sms’t wordt. Dan hebben we het nog niet eens over het sms-en van gradebook cijfers. Dan loopt je aantal in de miljoen sms of 100 kilo-euro per maand. Zijn er instellingen die dat betalen?

Blackboard Usergroup

Ik ben vandaag met mijn collega, Marion Coenraad, in Nijmegen bij de Radboud Universiteit, voor een bijeenkomst van de Blackboard Usergroup. Ook te vinden op ning. Het netwerk bestaat uit een mengeling van functioneel en applicatiebeheerders uit MBO, HBO en universiteiten. Voor ons de eerste, en prettige, kennismaking met dit netwerk. De gebruikersgroep is laagdrempelig, toegankelijk en iedereen wisselt openlijk allerlei ervaringen uit op het gebied van beheer van Blackboard.

Algemene conclusie: de manier waarop het beheer van Blackboard is ingericht kan erg verschillen. Van centraal naar decentraal en gedelegeerd, van formeel tot informeel, van pragmatisch tot principieel, van model-volgend tot ad-hoc. Toch blijkt dit niet tot grote verschillen in tevredenheid van eindgebruikers te leiden. Wat blackboard zelf betreft en de overstap naar versie 8.x, 9.x of ‘Next Generation‘: wij gebruiken niet het content-management-systeem en zitten op versie 7.3. De beperkte nieuwe functionaliteit en de problemen die upgrade op dit moment oplevert geven mij geen haastige overstap neiging. Ik verwacht voorlopig nog wel even toe te kunnen met 7.3.

Voor een verslag van de onderdelen, klik ‘Continue Reading’.

Continue reading

Aan elkaar knopen…

  Feedburner 

Ik kreeg afgelopen vrijdag wat vierkante ogen van rapportages die opgeleverd moesten worden, dus voor de afleiding even een tussendoortje opgepikt. De aanleiding was het roosterbureau, die kwam met de vraag waarom we geen schermen hebben hangen voor roosterinformatie. Die vraag wordt elders beantwoord, maar ik bedacht wel “zou het niet leuk zijn als extra service als we roosterinfo naar de mobiel kunnen brengen”.

Een half uurtje googlen leverde de volgende stappen op:

  • Maak een omgeving aan in Blackboard voor het roosterbureau van de betreffende school/college/team/entiteit. Het moet een omgeving zijn waarvan de mededelingen een “natuurlijke groep” moeten bereiken.
  • Maak een account aan dat alleen tot deze omgeving toegang heeft.
  • Installeer de building block “Announcements2RSS” van Avans Hogeschool. Deze building block geeft een feed. Deze feed is account-afhankelijk en wordt gevuld met de mededelingen uit alle omgevingen waar het account toegang toe heeft.
  • Maak een portal-module aan die de RSS link voor elk account aanbiedt.
  • Log in als het account dat de roosterwijzigingen moet volgen, zet de RSS-module aan en kopieer de RSS feed. Deze feed is nogal lang en “lelijk”. Testen laat zien dat iGoogle het wel slikt, maar Google reader weer niet.
  • Om de feed in te korten: maak bij feedburner er een “nette” feed van. Kun je ook later gelijk zien hoeveel mensen zich abonneren. In dit geval: http://feeds.feedburner.com/svcd (SvCD = School voor Commerciele Dienstverlening)
  • Deze feed wordt gegeven aan de mobiele variant van Google-Reader. Gevonden hier. Hiervoor hoeft de publiceerder èn de lezer geen account bij Google te hebben.
  • Het adres is http://www.google.com/reader/m/view/feed/<metjefeedadreserachter>. Google geeft hiermee de mogelijkheid om elke willekeurige feed aan te bieden in een voor mobieltjes geoptimaliseerde pagina.
  • In dit voorbeeld wordt dat dan:

http://www.google.com/reader/m/view/feed/http://feeds.feedburner.com/svcd

  • Dat is nog steeds “lelijk”. Dus op een domein wat we hebben lopen een URL aangemaakt hiernaartoe: http://svcd.contentinopel.nl
  • Getest op mijn oude Nokia en het werkt luid en duidelijk.

Opmerkingen:

  • Het vergt wel een mobiel met internettoegang. Dataverkeer van Google Reader Mobile is gering, gezien de tekstuele inhoud.
  • Blackboard systeembrede mededelingen komen ook mee. Opzich niet erg.
  • Onduidelijk is nog hoe snel de ene feed de andere oppikt. Het moet van Blackboard, naar FeedBurner, naar Google etc. Het mag maximaal een lesuur duren om te verversen…
  • Het vervangt niet overige communicatie, niet iedereen heeft internet op zijn mobiel.
  • Er zijn wel veel meer systemen die “messaging” doen etc., maar deze manier is redelijk laagdrempelig om te implementeren.
  • Omdat de feed publiek is, moeten de mededelingen geen info bevatten over de reden van lesuitval, ziekte en andere persoonlijke zaken.