Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering
De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de VS.
Dit nummer werd uit het Engels vertaald door:
Verder werkten mee:
Apple heeft de iPhone in nog eens 21 landen uitgebracht, wat het totaal op 43 brengt. Reuters bericht dat Rusland de iPhone in oktober 2008 ook zal krijgen, en wij zijn er zeker van dat meer landen zullen volgen, elke keer als Apple nieuwe deals met desbetreffende telefoonbedrijven sluit. Apple werkt voortvarend aan zijn plan om de wereld te veroveren.
Er is veel te doen geweest over het feit dat de iPhone nu een potentieel bereik van 600 miljoen klanten heeft, maar dat getal is een overdrijving. We weten simpelweg niet hoe de telefoon op een bepaalde markt zal verkopen, noch kennen we de details van de afspraken tussen Apple en de lokale telefoonbedrijven. Wat mij veel meer interesseert zijn de gevolgen voor de verkopen in de App Store, want als het aantal werkende iPhones zelfs maar met een miljoen hier en daar groeit, dan zou dat kunnen resulteren in een significante toename van de verkoop van de afzonderlijke programma's in de internetwinkel.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Apple werkt er hard aan aan om ondoorgrondelijk te zijn, vooral de laatste tijd. Recente opwaarderingen van software, zoals iPhone 2.0.2, geven alleen maar "foutherstel" zoals te zien in hun uitgifte-document en problemen met het lanceren van MobileMe en uitgebreide email-problemen werden ofwel helemaal niet, ofwel alleen maar op een halfslachtige manier toegegeven. (zie "Vergelijking Apple's berouw over MobileMe met Google en Netflix", 19-08-2008.)
Om die reden is het misschien zo verrassend dat er een handig communicatie-achterpoortje is ontstaan, waar duidelijke antwoorden vandaan komen die de woordvoerders van Apple niet kunnen bieden, te weten Apple's directeur Steve Jobs zelf.
Een lezeres van TidBITS vertelde ons dat ze van Jobs per e-mail een persoonlijk antwoord had gekregen aangaande een probleem met de iPhone waar sommige mensen mee te maken hebben. Na opwaardering van de iPhone 2.0 software en van iTunes 7.7.1, kon ze geen programma's van derde partijen laden en iTunes liet zien dat het geheugen van de iPhone leeg was. Volgende opwaarderingen van de iPhone gaven geen oplossing voor het probleem. (Voor meer reacties van klanten betreffende dit probleem, zie deze draad bij Apple Support Discussion.)
Het antwoord van Jobs op haar mail bestond uit één zin en die is direct en nuttig: het probleem wordt erkend en het geeft een tijdsaanduiding voor de oplossing: "Dit is een bekend iPhone probleem dat wordt opgelost bij de volgende opwaardering in September". (We hebben al eens eerder een mail van Jobs gezien, en zijn kenmerk is die directe telegramstijl. In Januari 2007 vertelde een lezer dat Jobs op zijn per e-mail aan de directeur verzonden klacht, betreffende de merkwaardige betaling van $5 voor een Draft N-enabler om een verborgen Wi-Fi capaciteit in een groot aantal Mac-modellen aan te kunnen zetten, had geantwoord: "Het is de wet".)
Jobs is duidelijk niet gebonden aan de geheimhouding die hij zijn werknemers heeft opgelegd, en, eerlijk gezegd doet dat fris aan. Niet zozeer omdat een klant een e-mail kan sturen naar [email protected] en een antwoord krijgt, maar omdat het antwoord inhoud heeft. Als Jobs de normale manier van doen van Apple had gevolgd, dan had hij geanwoord met het soort niet-vertrouwenswekkende gebakken lucht die de meeste bedrijven gebruiken: "Welbedankt voor uw e-mail. Apple werkt er hard aan om zijn producten zo goed mogelijk te maken…". Bla-bla-bla.
Wij hopen dat Jobs bij Apple een meer open manier van communiceren gaat bevorderen. We begrijpen de noodzaak voor geheimhouding om onaangekondigde producten te kunnen beschermen, maar de recente moeilijkdoenerij van het bedrijf is contraproductief. In plaats van het imago neer te zetten dat geen nieuws goed nieuws is, zorgt de koppige zwijgzaamheid van Cupertino ervoor dat de klanten van Apple en ook wij die het bedrijf volgen, zich gaan afvragen hoe slecht de dingen er achter het gordijn wel niet voorstaan.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Hoewel de lancering van MobileMe niet gezien kan worden als topprestatie in het uitbrengen van een nieuw Apple-product, moeten zelfs de zuurste critici schoorvoetend toegeven dat de webinterface een van de beter ontworpen voorbeelden op de markt is. Helaas is het ook een van de minst veilge. Apple laat iedereen meeluisteren met alle communicatie die je met de site hebt, inclusief de inhoud van mail- en agenda-updates.
AppleInsider probeerde de bezorgdheid weg te masseren, toen ze op 15 augustus 2008 aandacht besteedden aan MobileMe. Zo was SSL-versleuteling, als techniek om verbindingen te beveiligen tegen kwaadwillende activiteiten als sniffing en hijacking, niet nodig, want:
"Beveiliging van gegevensoverdracht in de internetprogramma's op MobileMe is gebaseerd op vooraf ge-authenticeerde uitvoering van de JSON-gegevensoverdracht tussen autonome Java-programma's op de cliëntcomputer enerzijds en anderzijds Apple's Cloud (nvdn: de host server van MobileMe); de gegevensoverdracht wordt niet (zoals webpagina's) via SSL versleuteld over HTTPS. De enige echte webpagina's die MobileMe met de server uitwisselt zijn de HTML-, Javascript- en CSS-bestanden waar de programma's uit bestaan. Deze hebben geen SSL-versleuteling nodig, als ze eenmaal door de gebruiker ge-authenticeerd zijn. Hieromtrent is bij sommige internetgebruikers onnodig paniek onstaan, omdat zij het bekende SSL-slotje gelijkstellen aan internetbeveiliging. Natuurlijk is geen enkele e-mail nog een veilig medium, zodra deze de server verlaten heeft."
"Als Apple SSL-versleuteling in de browser zou toepassen zou het iedere gegevensoverdracht alleen maar vertragen, zonder werkelijk iets aan de veiligheid ervan toe te voegen; het zou de beginner een vals gevoel van veiligheid geven, en de aandacht afleiden van reële bedreigingen".
Dit is helaas grote onzin. De Star Trek-fans onder jullie kennen de term "techno babble": de fantasietaal vol technologietermen die acteurs gebruiken om teksten de schijn van wetenschappelijke precisie te geven. Het "wisselen van schildfrequentie in harmonie met de tachyonstraal van de Klingon" is pure nonsens, die echter authentiek klinkt. Hetzelfde geldt voor de tekst: "Beveiliging van gegevensoverdracht in de internetprogramma's op MobileMe is gebaseerd op vooraf ge-authenticeerde uitvoering van de JSON-gegevensoverdracht tussen autonome Java-programma's op de cliëntcomputer enerzijds en anderzijds Apples Cloud". Hier staat niet meer dan: je logt in, en vervolgens wordt Javascript gebruikt om de communicatie met MobileMe uit te voeren. Hier wordt niets op magische wijze beveiligd.
Zoals Jens Alfke in zijn Thought Palace-blog stelt, is alleen je eerste inlogactie naar MobileMe versleuteld; de rest van de sessie wordt in platte tekst verzonden. Als iemand in je netwerk zin heeft om je verbinding te "sniffen" en je e-mail te lezen, dan houdt niets hem tegen.
AppleInsider stelt in feite het volgende: "Apple controleert dat je werkelijk een gebruiker bent op het moment dat je inlogt. Alle verdere communicatie tussen browser en hun servers wordt zó de ether in gestuurd. En volgens ons zou SSL-beveiliging de prestaties alleen maar vertragen, en niets toevoegen aan de veiligheid". En met het laatste deel van die conclusie maken ze een enorme fout.
Alle waar is naar zijn geld - of zou dat moeten zijn -- Eerlijk is eerlijk: ook Yahoo Mail en Hotmail gebruiken SSL alleen voor de eigenlijke inlogprocedure, en Google heeft pas onlangs de mogelijkheid om je hele sessie onder SSL te voeren aan Gmail toegevoegd. Dat is echter geen excuus voor Apples keuzes. Yahoo Mail en Hotmail zijn gratis, in tegenstelling tot MobileMe, dat 99 dollar per jaar kost. Je kunt me veeleisend vinden, maar ik verwacht meer van een commerciële dienst. Google biedt SSL als optie zonder bijbetaling, en vrijwel alle commerciële Webdiensten die e-mail faciliteiten aanbieden hebben SSL standaard of als optie.
Er zit nóg een subtiele, maar belangrijke tekortkoming in de wijze waarop Apple omgaat met gebruikersverificatie. Zoals Alfke aangaf resideert de beveiligde inlogpagina op auth.apple.com, maar de rest van MobileMe gekoppeld is aan het me.com domein. Hiermee wordt de verbinding tussen het SSL-certificaat waarmee een domein wordt geverifieerd en het domein waar het grootste deel van het [MobileMe] verkeer wordt afgehandeld verbroken, zodat gebruikers kwetsbaar worden voor omleidingsaanvallen vergelijkbaar met het onlangs bekend geworden DNS beveiligingslek (zie "Nog geen patch van Apple voor gevaarlijk zwak punt van DNS", 24-07-2008). Ook lokaal kan een DNS om de tuin geleid worden, bijvoorbeeld als een aanvaller een netwerk overspoelt met antwoorden voor niet-beveiligde domeinen: bijvoorbeeld op een hotspot waar je op inlogt.
Een kwaadwillende kan zodoende het me.com domein tijdelijk kapen en je doorverwijzen naar een malicieuze website zonder zich te hoeven bekommeren om je login-procedure; die wordt immers nog steeds afgehandeld via het apple.com domein waar niets mee aan de hand is. Nu ligt het niet voor de hand dat kwaadwillenden de complete MobileMe interface zullen klonen om een complete malicieuze website op te zetten; veel meer voor de hand ligt een aanpak (zoals ik recentelijk op de DefCon hacker bijeenkomst demonstreerde via wifi) waarbij je omgeleid wordt naar een kwaadwillende webpagina, die snel je Mac besmet, waarna je even zo snel weer wordt teruggeleid naar de bona fide me.com voordat je het in de gaten hebt.
Het beveiligen van een complete sessie met SSL leidt niet tot "vertraging in alle uitwisselingen van gegevens zonder de veiligheid noemenswaardig te vergroten". Omdat MobileMe een webtoepassing is is het niet afhankelijk van het (her)laden van complete pagina's; er gaan door de bank genomen slechts kleine pakketjes gegevens heen en weer. (De JSON uit de alinea koeterwaals hierboven is in feite een formaat voor minimalistische JavaScript objecten.)
(Apple heeft wel zijn 'legitimatie-cookie', dat door je browser wordt opgeslagen, van een beveiligde code voorzien. Dit 'toegangskaartje', waarmee het mogelijk is om over sessies heen ingelogd te blijven, wordt alleen uitgewisseld met auth.apple.com, en wel via SSL. Hiermee is side-jacking, wat tot voor kort wel werkte met Gmail en andere Google diensten (totdat ze daar wakker werden en dergelijke toegangskaartjes gingen beveiligen) onmogelijk. Zie "Sidejacking doorbreekt beveiling van Gmail en andere diensten", 27-08-2007.)
En nu het goede nieuws, en hoe bescherm je jezelf -- Het is dus in principe mogelijk dat iemand je verbinding kan volgen als je en plein public verbinding maakt; een omleidingsaanval is echter bijzonder onwaarschijnlijk. Bovendien zijn alle andere MobileMe diensten, met uitzondering van de web-interface en iDisk, beveiligd zoals het hoort.
Als je een MobileMe e-mail account aanmaakt zal dat standaard voor een beveiligde verbinding kiezen; ook de iCal synchronisatie (zowel 'push' als handmatig) blijkt via SSL te verlopen. Ik kon met een sniffer op mijn eigen machine geen inzage krijgen in de gegevens die voor e-mail of kalender synchronisatie werden uitgewisseld. Verder is de iChat aanmelding beveiligd, en installeert MobileMe digitale certificaten die het mogelijk maken om beveiligde chats met andere iChat gebruikers te voeren - in tegenstelling tot AOL Instant Messenger en vele andere gratis chatsystemen. Hou er wel rekening mee dat als je iChat gebruikt met MobileMe versleuteling, en je chat met een niet-beveiligde AIM gebruiker, dat de betreffende (iChat) verbinding niet beveiligd is.
De MobileMe web interface is een schot in de roos, zelfs al heb ik hem meestal niet nodig omdat ik vrijwel altijd mijn Mac of iPhone onder handbereik heb. Maar omdat de situaties waarin ik het zou willen (kunnen) gebruiken vrijwel altijd gepaard gaan met onbeveiligde systemen en netwerken, zoals internet café's onderweg zal ik toch van deze handige mogelijkheid moeten afzien en beter beveiligde mogelijkheden moeten zoeken totdat Apple besluit om SSL volledig te ondersteunen.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
In een email gestuurd aan gebruikers van MobileMe op 18 augustus 2008, kondigde Apple aan dat het bedrijf alle abonnementen verlengt met 60 dagen. Ieder betaald of test-abonnement dat op middernacht 19 augustus 2008 aktief was, krijgt twee extra maanden. De verlenging met 60 dagen wordt gegeven aan abonnees die wellicht al de 30 dagen verlenging ontvingen die Apple eerder toekende (Zie "MobileMea Culpa: Apple biedt verontschuldigingen aan en verklaart Tiger-situatie nader", 16-07-2008, voor diegenen die in aanmerking kwamen voor die verlenging.) De uitbreiding met 60 dagen zal de komende dagen worden toegevoegd aan de abonnementen.
De totale 90 dagen verlenging van het abonnement komt neer op $ 24 voor iedere abonee op .Mac/MobileMe dat normaal $ 99 per jaar kost. (Tip: koop de uitvoering in een doosje van MobileMe voor een nieuw abonnement of een verlenging om geld te besparen; Amazon verkoopt het Family Pack van MobileMe voor $ 109,99 in plaats van $ 149, bijvoorbeeld.) Hoewel Apple geen aantal gebruikers noemt van MobileMe, wordt over het algemeen een aantal van 2 miljoen genoemd. Ik hoorde althans dat getal een paar jaar geleden van een werknemer van Apple, dus ik verwacht dat het aantal gebruikers nu hoger ligt, vooral gezien de rol die MobileMe nu speelt voor de waarschijnlijk zes miljoen gebruikers van de iPhone en de iPod touch. Dat betekent dat Apple nu op zijn minst van $ 48 miljoen afziet aan MobileMe-abonnementsomzet en wellicht zelfs wat meer.
Die financiële aderlating verklaart gedeeltelijk waarom Apple niet bepaald verontschuldigend lijkt over de overgang naar MobileMe, die werd gekenmerkt door kwijtgeraakte mail, uitval van de dienst, synchronisatieproblemen en zo nog wat. Ik vermoed dat voor Apple intern de verlenging van het abonnement een duidelijke verklaring is omdat het een aanzienlijke hoeveelheid geld is voor het bedrijf. Oftewel, er worden nogal wat opbrengsten uitgesteld omdat het eigenlijk betekent dat Apple nog 90 dagen moet wachten totdat de opbrengsten van de verlenging van de MobileMe-abonnementen binnenkomen.
Maar voor een individuele gebruiker is $ 24 niet zo veel en als je uren bezig bent geweest met email die je kwijt bent of wanhopig bent over problemen met synchroniseren, dan is $ 24 niet bepaald een vergoeding daarvoor, vooral als geen enkele communicatie van Apple begint met "Het spijt ons!" Apple heeft diverse officiële verklaringen gegeven over de stand van zaken die aangaven dat er problemen waren (hoewel Steve Jobs's interne email verreweg de meest duidelijke was), maar slechts één gebruikte het woord "verontschuldigen" en dat ook maar één keer.
Dat eerste emailbericht aan abonnees van MobileMe luidde gedeeltelijk:
"We willen onze verontschuldigingen aanbieden aan onze trouwe klanten en onze waardering uiten voor hun geduld door alle huidige abonnees een gratis automatische verlenging op hun MobileMe-abonnement aan te bieden van 30 dagen".
Dit was ook het enige officiële bericht dat uitlegde wat er aan de hand was. Alle volgende verklaringen, waaronder de email van vandaag, vroegen om geduld en waren vage mededelingen betreffende de overgang naar MobileMe die heftiger was als verwacht, maar ze herhaalden niet het excuus of gaven details. Uit het bericht van vandaag:
"We hebben al vele verbeteringen in MobileMe aangebracht, maar er moeten er ook nog steeds veel gedaan worden. Als beloning voor het geduld van onze klanten krijgt elk MobileMe abonnement vanaf vandaag een gratis verlenging met zestig dagen. Dit komt bovenop de maand die de meeste abonnees al ontvangen hebben. We doen ons uiterste best om van MobileMe iets te maken waar we allemaal trots op kunnen zijn. We zijn ons ervan bewust dat de lancering van MobileMe niet op rolletjes liep en proberen dat recht te zetten. Wij stellen uw geduld hiervoor echt op prijs."
Als schrijver valt het mij op, dat aankondigingen van Apple er vaak een beetje omheen draaien. Als ouder kwam dat vaak herhaalde zinnetje naar boven, als we het ene stoute kind sorry willen laten zeggen tegen de ander: "Zeg het zo hard dat hij het kan horen en dat je het meent". Het zou aardig zijn om ook eens te kijken naar andere, recente in het oog springende storingen.
Zowel MobileMe Mail als Gmail van Google hadden op 11 augustus gedurende een aantal uren met een storing te maken. In het recente e-mailbericht van Apple werd met geen woord gerept over die storing als onderdeel van de rommelige transitie, het enige wat ik kon vinden waren een paar notities op de MobileMe System Status pagina (bladwijzer opslaan, jongens!) Er was geen enkele melding van de storing op de semi-anonieme MobileMe Status blog; het meest recente bericht is van 29 juli 2008 en dat claimt dat alle verloren email weer hersteld was, en belooft nog een bericht later in de week (wat niet komt). Sinds de eerste versie van dit artikel heeft Apple de MobileMe Status blog officieel opgedoekt. Waarschijnlijk omdat ze ook wel in de gaten hadden dat het vanaf het begin allemaal nooit erg geloofwaardig overgekomen is.
Google, daarentegen, plaatste al heel snel een excuus op de Official Gmail Blog met de titel: "We voelen je pijn en zeggen sorry". Verder wordt redelijk gedetailleerd aangegeven wat er fout is gegaan, waarom dat zo is, en wat Google er aan doet om het in de toekomst te voorkomen. Ik weet niet of Google de betalende abonnees van de Google Apps Premiere Edition (met een garantie voor een 99,9% van de tijd werkende dienst) iets heeft beloofd, maar omdat Gmail voor de meeste gebruikers gratis is, is een verontschuldiging alles wat je kan verwachten.
Een ander voorbeeld is hoe Netflix omging met de berichtgeving rond de storing in hun verzendsysteem. Binnen twee dagen kwam er een e-mailbericht met de titel: "Onze excuses voor de vertraging in de verzending van uw dvd's". In de eerste paragraaf van het bericht werd uitgelegd wat er aan de hand is, de volgende paragraaf gaf de excuses en liet gebruikers weten dat ze een compensatie voor het ongemak konden tegemoet zien. De derde paragraaf bevatte nogmaals een verontschuldiging en een telefoonnummer voor de klantenservice voor het geval men verdere hulp nodig had. En dit was voor een entertainment-dienst, niet zoiets als MobileMe of Gmail waar sommige mensen op vertrouwen voor hun zaken.
De volgende dag kwam Netflix met min of meer hetzelfde bericht, "Onze excuses voor de vertraging in de verzending van uw dvd's", dat een uitleg gaf over wat er fout gegaan was en dat alles weer zou moeten werken. Er volgden nog een aantal verontschuldigingen en het bericht bevatte ook deze knap in elkaar gezette mededeling:
"Wij zijn er trots op dat we u altijd weer kunnen verrassen, maar dat is deze keer niet gelukt. Onze excuses daarvoor, we geven u daarom 15% krediet op uw rekening in de komende dagen. U hoeft daar niets voor te doen. Dit wordt automatisch verrekend met uw eerstvolgende rekeningoverzicht."
Netflix heeft ook op uitstekende wijze gebruikers met updates op het Netflix Community Blog op de hoogte gehouden van de situatie, te beginnen op 12 augustus met elke dag een of twee berichten totdat de situatie op 15 augustus recht gezet was. Dat is nog eens berouw tonen. Fouten toegeven, verontschuldigende toon aan slaan en binnen vier dagen extra krediet geven.
Apple ontkent niet dat er problemen zijn, noch dat ze doen voorkomen dat alles wel meevalt; dat is goed. Maar in ieder geval naar mijn mening tonen de blog en email berichten van Google en Netflix veel meer berouw, ze zijn echt teleurgesteld dat ze mij niet tevreden konden stellen. Ik het ook een beter gevoel bij berichten van echte mensen, vooral de berichten op de Netflix blog gaven mij het idee dat de Netflix jongens hard aan het werk waren om het probleem op te lossen en dat de storing hen in het geheel niet lekker zat. De anonieme en pseudonieme berichten van Apple hebben een dergelijke uitstraling helemaal niet.
Hoewel sommige mensen excuses liever uit de weg gaan omdat dat schuld bekennen zou zijn, is er ook veel bewijs dat een welgemeende verontschuldiging ook rechtszaken kan voorkomen, omdat men vaak gaat procederen wegens vermeende onwil. Het is de moeite waard om het DC Bar artikel van Sarah Kellogg, getiteld "The Art and Power of the Apology", te lezen. Er is ook een hele website (Perfect Apology) gewijd aan het leren verontschuldigen en aan een uitleg waarom dit zo handig is.
Ik spreek hier niet alleen als commentator, maar ook als iemand die meer dan eens in onze 18-jarige geschiedenis e-mails naar tienduizenden TidBITS abonnees de mist in heeft laten gaan. De moraal van het verhaal is: als je een probleem tegenkomt dat grote aantallen gebruikers treft, breng de omstandigheden van de situatie dan snel en duidelijk naar buiten, laat het bericht van een echt persoon komen en zeg alsjeblieft zo hard sorry dat iedereen het kan horen!
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Ik houd van wijn. Ik zou makkelijk een wijnsnob kunnen worden, maar er zijn drie beperkingen: Ik heb te weinig geld, een te slecht geheugen voor namen en smaken, en nou ja, het is moeilijk om overeind te blijven als een sommelier grinnikt over mijn Frans.
Ik kan niets bedenken om wat aan mijn Frans te doen, maar 20 jaar geleden leerde ik hoe het gebrek aan geheugen voor een deel te compenseren betreffende het geldgebrek: Ik koop goedkope wijnen en vergeet waar ik ze neerzette. Na 5 of 10 jaren kom ik ze weer tegen en merk dat ze best fijn geworden zijn.
Echter moeten ze wel het juiste soort goedkope wijn zijn. Als je goed druivensap fermeteert en en weet wat je aan het doen bent, kun je een drinkbare wijn maken. Deze wijn is goedkoop te produceren maar niets ervan zal verbeteren bij het verouderen. Daarentegen, inplaats van de wijn dadelijk te bottelen, kun je hem voor een jaar of twee bewaren in kleine eiken tonnen. Hierdoor stijgen de kosten iets en als je ze tenslotte bottelt, zal die wijn vies smaken. Dat soort wijn moet je weg doen. De vieze smaak komt door tannines die uit het hout gelekt zijn. Over de jaren heen zullen de tennines geleidelijk geoxideerd wordem. In combinatie met het druivensap kunnen die oxidatieprodukten complex worden en om van te genieten zijn.
Jarenlang hebben mijn vrouw en ik met deze strategie een kelder opgebouwd. We kopen kisten matig geprijsde wijnen die verouderden op eiken, en plaatsten ze achter andere vaten, zodat we vergaten dat ze er waren. Een aantal jaren later kwamen we ze tegen. Zo kunnen we betere wijnen drinken dan ons budget normaal zou veroorloven. Maar we hebben geen idee wat voor wijn we bezitten. We weten zelfs niet eens hoeveel flessen er in de kelder zijn.
Deze zomer besloten we dat de tijd gekomen was om de troep te sorteren, of zoals de dingen gebeuren, oordeelde mijn vrouw dat voor mij de tijd gekomen was om de troep uit te zoeken. Nu organiseren niet mijn sterste punt is, hoopte ik wat software te vinden die me zou helpen.
Commerciele variëteiten -- Om echt behulpzaam te zijn zou een computer meer moeten doen dan alleen maar een lijst van onze flessen te maken, hij zou uit zichzelf een lijst van de flessen moeten genereren. Een $ 199 combinatie van hardware en software is ontworpen om precies dat te doen: IntelliScanner Wine Collector 250. Een handmatige scanner leest de bar code die tegenwoordig op bijna iedere fles gedrukt staat, dan komt er een toepassing aan te pas die over het internet de wijn opzoekt in een database. Dat leek me schitterend, dus vroeg ik er een aan en probeerde hem meteen toen hij arriveerde. Ik scande 10 flessen uit verschillende landen. Helaas, Wine Collector gaf wat informatie voor slechts twee wijnen en vond of geen of onjuiste informatie voor de rest. Paul Scandariato van IntelliScanner legde uit, "Alhowel onze database 67.000 wijnen bevat, is dat maar een fractie van het aantal wijnen die in de wereld verkrijgbaar is".
Wanneer mijn Mac geen lijst met flessen kan genereren, kan het wel dienen als een vel gelijnd papier met een lijst: een spreadsheet. Die lijst moet echter wel een heleboel tekst bevatten, en het is over het algemeen lastig om goed geformatteerde tekst in een spreadsheet te plaatsen. De Mac zou daarom ook formulieren moeten aanbieden voor het invoeren van gegevens.
Dit is wat de gespecialiseerde wijnkelder-programma's doen. Helaas geven deze formulieren vaak te veel details, details die mij niet interesseren, en er ontbreken ook altijd een paar. Ik vind het niet leuk om een gecompliceerd formulier in te moeten vullen dat gemodelleerd is naar het gebruik van een ander. Ik heb er dus voor gekozen om geen gespecialiseerd programma te gebruiken, maar zelf een formulier te maken met een al bestaand systeem. Dit heb ik ooit gedaan met AppleWorks, maar een alternatief is Bento, een product met een prijskaartje van $ 50, uit de stal van FileMaker.
Mijn eigen lessen -- Bento biedt een eenvoudige interface om snel de soort informatie te kunnen bepalen die ik bij wil houden, de kolommen van een spreadsheet of, in database jargon, de velden. Na het definiëren van de velden, sleepte ik ze naar een invoerformulier en was ik klaar om records aan te maken. Om een lijst van wijnsoorten aan te maken klikte ik op een knop genaamd "Table" en werkte ik een aantal aankruisvakjes af naast een lijst velden. Ieder kruisje introduceerde dat veld als een kolom. Ik plaatste de kolommen waar ik ze wilde hebben, en stelde vervolgens een soort Spotlight in om "smart collections" in te stellen, vergelijkbaar met slimme mappen in de Finder. Voor een aantal paste ik de kolommen aan. Ik was nu klaar om informatie in te voeren over wijnen op de manier die ik het meest handig vind, en het klikken op een pictogram toont mij een handige lijst van onze witte wijnen met twee sterren, of onze rode wijnen met drie sterren.
Bento is in de markt gezet als een persoonlijke database, maar in tegenstelling tot FileMaker Pro, is Bento niet ontworpen om complexe databases te maken. Feitelijk is Bento ontworpen om lijsten te beheren. Het verschil tussen databasebeheer en lijstenbeheer is subtiel, maar essentieel. Om complexe data effectief op te slaan en te manipuleren, moet een databasebeheerder informatie herleiden tot de kleinst mogelijke elementen, gecombineerd met uniforme formaten en zonder dubbelingen. In tegenstelling hiermee doet een lijstbeheerder eigenlijk niet meer dan vinden en sorteren. Dat betekent dat de informatie op een natuurlijke manier opgeslagen kan worden. Veel programma's zijn geen databases, maar lijstbeheerders, denk maar eens aan Adresboek van Apple. Daarom kun je in Adresboek een telefoonnummer invoeren in het formaat dat jij wil. Een database met telefoonnummers zou echter vereisen dat je dat nummer opdeelt in een aantal afzonderlijke velden, zoals landnummer, kengetal, abonneenummer en eventueel een toestelnummer. (Ik moet daaraan toevoegen dat onder de motorklep van zowel Adresboek als Bento motoren zitten die complexe databases kunnen beheren, maar die lopen maar op één cylinder.)
Het instellen van een databasebeheerder vereist veel kennis en planning, maar het instellen van lijstbeheerder niet. Je hoeft niet meer te doen dan te bepalen hoe je je lijst wil kunnen sorteren (soort wijn, prijs, enz.) en deze informatie in aparte velden te zetten. De resterende informatie kun je opdelen in welke brokken dan ook, wat je maar handig vindt.
In theorie verloopt het proces van het instellen van een lijstbeheerder als volgt: je pakt pen en papier, denkt na over hoe je je lijst wilt kunnen sorteren, neemt een besluit over de velden die je nodig hebt, ontwerpt een formulier voor het invoeren van gegevens en je gaat dit vervolgens achter de computer aanmaken. In de praktijk denk je over het probleem na, werkt dat uit achter de computer door wat gegevens in te gaan voeren, en ontdek je dat je wat categorieën vergeten bent, of een paar teveel hebt. Je past de velden op het formulier vervolgens aan, voert nog wat meer gegevens in, en je ziet dat je op sommige plekken teveel informatie hebt, en op andere te weinig. Nadat je dat aangepast hebt, ontdek je nog meer mogelijke verbeteringen. Uiteindelijk heb je alles goed staan, maar een week of een maand later maak je nog wat aanpassingen.
Bento vereenvoudigt dit proces door een eenvoudige grafische interface aan te bieden die de gebruiker maar weinig keuze geeft. Vanuit het perspectief van een database-programmeur zijn de keuzes zo beperkt dat je er laaiend van wordt. (Dit wordt bewezen door de recensie van Jeff Porten van de pre-release versie van Bento; zie "FileMaker's Bento: Onrijp en een beetje verdacht", 14-11-2007.) Je kunt bijvoorbeeld van een veld niet verplicht stellen dat het gegevens bevat. Het doel van Bento is dan ook om eenvoudige lijsten voor individuen te beheren, niet complexe gegevens voor bedrijven. Wanneer ik vergeet om een botteljaar in te voeren zal me dat wel opvallen wanneer ik de lijst weergeef, en het alsnog invullen. Er zijn echter wel wat dingen waaraan ook ik me erger bij Bento - vooral het feit dat ik geen record kan verwijderen wanneer ik in een smart collection zit vind ik irritant - maar in zijn algemeenheid vind ik de beperkingen behulpzaam, en het pakket goed doorgedacht. In no-time had ik een wijndatabase gebouwd die aanvoelt als een professioneel product, en dat ik prefereer boven alles wat ik tot nu toe op de markt gezien heb.
Als ik ooit zou beslissen om onze boeken te catalogeren, dan zou ik daar Bento voor gebruiken. Ik zou Bento ook gebruiken voor klassieke cd's, een inventaris van hardware, of zowat elk ander type verzameling waarvan de beschrijvingen niet goed via een programma over het internet kunnen worden geraadpleegd. (Voor films op dvd, die goed worden beschreven in internetdatabases, gebruik ik DVDpedia) van Bruji. Aangezien Bento bestanden kan exporteren als kommagescheiden tekst, kan het ook worden gebruikt ter aanvulling van een spreadsheet om onderzoeksgegevens in te voeren.
Ik heb enkele kleinere bugs gezien in de gebruikersinterface van Bento, maar de actuele release lijkt redelijk goed afgewerkt en maakt goed gebruik van de tools die in Mac OS X 10.5 Leopard zijn ingebouwd (deze versie draait niet onder Tiger). Ik zou wat meer features kunnen wensen, en ik ben ervan overtuigd dat FileMaker ze gemakkelijk zou kunnen toevoegen, maar FileMaker zou nog gemakkelijker Bento kunnen overladen met feature-itis, en ik zal dan ook niet zo hard wensen. De huidige Bento is niet zo eenvoudig dat je oma er onmiddellijk zonder hulp mee aan de slag kan, maar een formulier voor het invoeren van gegevens maken en gebruiken is nauwelijks moeilijker dan Adresboek en iCal aanpassen en gebruiken. Aangezien Adresboek en iCal specifiek gemaakte lijstmanagers zijn, is dit een indrukwekkend geslaagd ontwerp.
Probeer mijn wijnkelderbestand -- Als je toevallig op zoek bent naar software voor een wijnkelder, dan mag je een lege versie van mijn Bento-bestand downloaden om te zien of je het kunt gebruiken als startpunt. Dit bestand is geen sjabloon (Bento kan geen sjablonen importeren), het is een lege versie van het echte databestand van Bento, het bestand "bento.bentodb" dat Bento in ~/Bibliotheek/Application Support/Bento/ bijhoudt. Als je al met Bento werkt, moet je voorzichtig te werk gaan om je actuele databestand te beschermen en kun je de forms van mijn bestand niet in het jouwe kopiëren, maar je moet ze opnieuw aanmaken. Bento zelf is beschikbaar voor een gratis proefperiode van 30 dagen.
Als je niet vertrouwd bent met Bento en het met mijn bestand probeert, dan kan je misschien het best twee instellingen in Bento veranderen. Bento zal je adresboek en kalender gebruiken, en het geeft deze standaard weer, maar het geheel wordt hierdoor ook wel wat onoverzichtelijk en rommelig. Om ze te verbergen, ga je naar het menu Archief, kies "Adress Book and iCal Setup", en schakel dan de beide selectievakjes uit in het dialoogvenster dat verschijnt.
Hieronder staan schermkopiëen van mijn invoerform en een listingform, plus uitleg voor sommige velden.
[Zie afbeelding]
[Zie afbeelding]
[Als je het artikel van Charles nuttig vond, vraagt hij je een bedrag dat gelijk is aan de prijs van je gemiddelde fles wijn te doneren aan Save the Children. Zie onderaan de pagina voor links naar de organisatie in verschillende landen.]
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
[De discussies waarnaar verwezen wordt, zijn in het Engels; daarom hebben we de titels niet vertaald - Tb-NL.]
Leopard - Microsoft Office Issue -- Na het updaten van het systeem wil Leopard de demo-versie van Microsoft Office opstarten in plaats van de geregistreerde versie. (6 berichten)
Archiving a Time Capsule -- Het backuppen van de harddisk van de Time Capsule lijkt eerst goed te gaan, maar gaat daarna tergend langzaam. Wat is er aan de hand? (2 berichten)
.Mac Slides are missing after iPhoto Update 7.1.4" -- MobileMe kent niet langer de optie om om foto's van anderen te delen als screensaver, maar de bestaande .Mac-foto's verschijnen nog steeds in screensavers. (14 berichten)
More Photo Backup Options While Traveling -- Lezers discussiëren over het onderweg backuppen van foto's. (2 berichten)
Why I Hate the Eye-Fi Share Wireless SD Card -- De ervaringen van Adam met de Eye-Fi Share kaart krijgen een oplossing voor elkaar voor het probleem, alsmede ervaringen van andere gebruikers. (10 berichten)
Using an iPhone when I drive --Een lezer wil onder het rijden met anderen kunnen praten. TidBITS Contributing Editor Mark H. Anbinder bespreekt enige aparaaten die in de nieuwe Audi's zijn ingebouwd. (4 berichten)
iWeb and MobileMe question --Het updaten van een website die op een bepaalde computer is gebouwd, blijkt tricky op een nieuwe laptop. (6 berichten)
iPhone Ver 2.0.2 "Bug Fix" -- Wie weet wat voor problemen er werden opgelost in iPhone 2.0.2? Wij niet, daarom steken we de draak met Apple en ook met de situatie rond "MobileMatig" . (6 berichten)
Cleaning out IMAP mailboxes -- Welke mogelijkheden zijn er om de grootte van IMAP-mailboxen van Mail te beheren? (3 berichten)
Office 2008 updates won't install -- Lezers hebben problemen met het installeren van de laatste updates van Microsoft Office en bespreken wat er is veranderd in het geïntegreerd pakket. (4 berichten)
Wine with Bento -- Het artikel van Charles Maurer over het bijhouden van zijn wijncollectie in Bento brengt een discussie op gang over programma's om andere artikelen zoals boeken en muziek te catalogiseren. (6 berichten)
MobileMe Web Interface Insecure, But Other Apps Get It Right -- Lezers discusiëren over de veiligheidsaspekten van MobileMe naar aanleiding van het artikel van Rich Mogull. (3 berichten)
Flash Problem -- Na een jaar zonder problemen weigert Flash correct te werken op de computer van een lezer. JavaScript kan de oorzaak zijn. (2 berichten)
I want to say goodbye to Outlook -- Het is moeilijk om afstand te doen van Outlook, maar er zijn alternatieven (3 berichten)
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering
