Bellerherkenning definieert wat de iOS en Mountain Lion Berichten-apps gebruiken als het impliciete "van"-adres bij het sturen van een iMessage naar een ander. Wanneer die andere persoon antwoordt, is haar antwoord naar jouw Bellerherkenningsadres gestuurd. Dat is simpel zat. Maar waar het lastig wordt is wanneer je verschillende e-mailadressen hebt die met elk iOS-apparaat en Mac geassocieerd zijn.
Laten we bijvoorbeeld zeggen dat Jeff de adressen [email protected], [email protected] en [email protected] heeft die allemaal geassocieerd zijn met Berichten in Mountain Lion op zijn MacBook Pro. Op zijn iPhone heeft hij alleen [email protected] en op zijn iPad alleen [email protected]. (Dit is niet alleen maar hypothetisch, tijdens het testen realiseerde hij zich dat hij elk apparaat had ingesteld met verschillende adressen.)
Als in Bellerherkenning in Mountain Lion [email protected] geselecteerd is en hij stuurt een sms met Berichten, zal het antwoord alleen op zijn Mac aankomen. Als Jeff Bellerherkenning wijzigt naar zijn [email protected], gaan de antwoorden naar zijn Mac en iPhone, als het [email protected] wordt, dan gaan ze naar zijn Mac en iPad.
Nu kan Glenn Jeff een iMessage sturen naar willekeurig welke van deze drie e-mailadressen en die zal in zijn Mountain Lion-chatvenster verschijnen. Maar wanneer hij een antwoord stuurt, verandert Berichten in Mountain Lion het afzenderadres altijd naar zijn Bellerherkenningsadres. Als Glenn op zijn beurt een antwoord stuurt op dat antwoord en hij verandert het bestemmingsadres niet, gaan zijn antwoorden alleen naar de apparaten die geassocieerd zijn met dat adres. (In het Berichtenvenster in Berichten kun je de aanwijzer boven de naam van een persoon achter het "Naar"-label laten zweven tijdens een conversatie en daarna op het naar beneden wijzende pijltje (niet de naam) klikken om het account te veranderen waar je je bericht heen wilt sturen.)
Dit geeft je een aantal mogelijkheden.
Je kunt ervoor zorgen dat alle apparaten alle berichten ontvangen, hetzij door overal dezelfde e-mailadressen in te voeren of door Bellerherkenning op elk apparaat op hetzelfde e-mailadres in te stellen. Dat is op dit moment de meest logische aanpak voor de meeste mensen.
Je kunt ook voor elk apparaat een specifiek iMessage-account kiezen en steeds dat adres als de Bellerherkenning-afzender gebruiken voor dat apparaat. Dit is een beetje absurd, maar je kunt ermee bereiken dat je een binnenkomend bericht op alle apparaten ontvangt, maar dat daaropvolgende antwoorden alleen naar één specifiek apparaat gaan. Zo zou Glenn bijvoorbeeld [email protected] kunnen instellen op al zijn apparaten, zodat iMessages naar dat adres overal verschijnen. Maar als het Bellerherkenningsadres op zijn Mac [email protected] is en [email protected] op zijn iPhone, dan zouden reacties op zijn op de iPhone geschreven antwoorden alleen naar de iPhone terugkomen. En zo kan hij een conversatie starten van een bepaald apparaat zonder dat de ontvanger weet dat het daar vandaan komt, ze kunnen gewoon antwoorden.
Deze tweede aanpak belicht wel een van de belangrijkste frustraties rondom Berichten. Als iemand dit apparaat-specifieke adres bewaart en later een nieuw bericht maakt (in plaats van te reageren op het laatste bericht van Glenn, of zijn algemene iMessage-addres te gebruiken), dan kan dit bericht terechtkomen op een toestel dat hij niet gebruikt! Bovendien kunnen alleen iPhones een telefoonnummer als iMessage-account gebruiken, dus is het goed denkbaar dat een vriend een sms stuurt naar het telefoonnummer van Glenn, voorbijgaand aan een eventuele eerdere iMessage-conversatie, waardoor de conversatie alleen nog maar naar zijn iPhone gaat.
Dus ook al heb je enigszins in de hand welk adres met je uitgaande berichten meegezonden wordt, de enige manier om te bepalen hoe mensen berichten naar jou sturen, is een en hetzelfde adres te gebruiken op alle toestellen.
Dit alles illustreert wat er ontbreekt aan Berichten. Apple wil ons blijkbaar niet de e-mail die gekoppeld is aan accounts, centraal laten beheren. Het beheer blijft verlopen via de afzonderlijke toestellen. Maar Apple valideert wel centraal e-mailadressen die gebruikt worden in iMessage en bevestigt dat ieder adres dat geen Apple ID is, op elk moment aan maar één Apple ID-account gekoppeld is. Een beetje hulp om helder te krijgen wat waarheen gaat, zelfs als we de informatie moeten beheren op een website of in een voorkeurenpaneel, zou veel verwarring en onnodig gepriegel kunnen voorkomen.
Lees reacties op dit artikel of plaats er een | Tweet dit artikel
Sinds de publicatie van "Take Control of Apple Mail in Mountain Lion" hebben verschillende mensen mij vragen gesteld over veranderingen in de manier waarop Mail in Mountain Lion omgaat met het "Van"-adres in uitgaande berichten. Eerst wist ik niet wat ik moest zeggen want ik had in mijn eigen tests geen verrassende dingen gezien, maar naarmate er meer klachten kwamen (waaronder een groot aantal op de discussiefora van Apple), werd duidelijk dat er iets niet in de haak was. Daarom ging ik op onderzoek uit. Het blijkt dat Mail in Mountain Lion uitgaande berichten inderdaad anders behandelt dan voorheen en voor sommige gebruikers kan het frustrerend lastig zijn om te voorspellen welk account Mail zal gebruiken als afzender.
In Apple Mail kun je zo veel verschillende accounts instellen als je maar nodig hebt, elk met een eigen uitgaande-mailserver en een of meer e-mailadressen. Als je een nieuw bericht maakt, of op een bericht reageert, kiest Mail een standaard Van-account voor je, maar kun je een ander account kiezen uit een venstermenu boven in het bericht. Dat is allemaal dik in orde en zo werkt het al zo lang als ik mij kan herinneren.
Maar in Mountain Lion heeft Apple de regels, hoe Mail het Van-account voor uitgaande berichten kiest, ingrijpend veranderd. Daardoor kan het gebeuren, als je niet zorgvuldig (en handmatig) elk uitgaand bericht controleert, dat je berichten verstuurt vanaf een ander adres dan de bedoeling was. Dit kan ernstige gevolgen hebben, bijvoorbeeld als je e-mail voor je werk verstuurt vanaf een persoonlijk account of andersom. Ik heb dit niet opgemerkt in de eerste paar weken waarin ik Mountain Lion gebruikte, omdat ik bijna altijd e-mail vanaf hetzelfde account verstuur en er niet wakker van lig als ik per ongeluk een keer vanaf een ander adres verzend. Maar voor veel gebruikers is deze verandering een ernstig punt.
Wat is er precies veranderd in het gedrag? Dit zijn mijn bevindingen, op basis van meer dan 100 experimenten, waarin ik elke combinatie van variabelen die ik maar kon bedenken heb getest.
In Lion en eerder is het gedrag als volgt:
Wanneer je antwoordt op een bericht, gebruikt Mail als afzender altijd het account waar het bericht aan gestuurd was. Het maakt niet uit wat er in je voorkeuren staat of waar het bericht is opgeslagen.
Als je een nieuw bericht maakt, gebruikt Mail het account dat je hebt opgegeven in het venstermenu "Verstuur nieuwe berichten van" in het voorkeurenpaneel Nieuw (met andere woorden, precies zoals dit menucommando zegt). De standaardkeuze, "Account van geselecteerde postbus", houdt in dat voor uitgaande berichten het account moet worden gebruikt dat gekoppeld is aan de postbus die geselecteerd is in de navigatiekolom van Mail. Maar als een lokale postbus ("Op mijn Mac") is geselecteerd, of als geen enkele postbus is geselecteerd, dan kiest Mail een Van-account op basis van een regel die ik niet heb kunnen blootleggen, zelfs niet na heel veel testen. En als je een specifiek bericht hebt geselecteerd, dan kan Mail, ongeacht waar dat bericht staat, een totaal ander Van-account kiezen, opnieuw zonder onmiddellijk heldere logica.
Kortom, Lion mag dan een tikje onvoorspelbaar zijn wanneer "Account van geselecteerde postbus" is ingesteld, maar over het algemeen is het gedrag voorspelbaar en bij antwoorden is het zowel consistent als logisch.
Anderzijds zie ik in Mountain Lion het volgende:
Bij het beantwoorden van berichten:
Voor berichten in een postbus op server-basis (bijv. IMAP of iCloud), gebruikt Mail de account voor die postbus, ongeacht de account waarnaar het bericht was gestuurd of ongeacht je voorkeuren. Dat is redelijk logisch en ook al is het anders dan vroeger, dan zou het resultaat meestal nog hetzelfde moeten zijn. Maar…
Voor berichten in een lokale (Op Mijn Mac)-postbus, als "Account van geselecteerde postbus" is gekozen in het popup-menu "Verstuur nieuwe berichten via" in het voorkeurpaneel Nieuw (dit is de standaardinstelling), dan gebruikt Mail… euh… een blijkbaar willekeurig gekozen account. Net zoals bij het aanmaken van nieuwe berichten in Lion, heb ik tientallen tests gedaan en telkens dacht ik dat ik de logica doorhad (zoals de bovenste account die geactiveerd is in het voorkeurpaneel Accounts; eerst iCloud, dan Gmail; de laatste account waarvan je post hebt verstuurd, enzovoorts), maar dan vond ik weer een uitzondering. Ik weet het echt niet; ik kan alleen maar zeggen dat Mail steevast dezelfde account lijkt te nemen zolang je de voorkeuren van je account niet verandert. Anderzijds is het wel zo dat als in het popupmenu Verstuur nieuwe berichten via één account is ingesteld, Mail die account gebruikt, ongeacht de account waarnaar het bericht was gestuurd. (Met andere woorden, antwoorden worden op dezelfde manier verwerkt als nieuwe berichten.)
Bij het aanmaken van nieuwe berichten gebruikt Mail de account die is ingesteld in het popupmenu "Verstuur nieuwe berichten via" in het voorkeurpaneel Nieuw. Net zoals in Lion is "Account van geselecteerde postbus" de standaardkeuze en voor server-postbussen lijkt dit ook zo te werken. Maar als er geen postbus is geselecteerd, of als een lokale (Op mijn Mac) postbus is geselecteerd, dan gebruikt Mail de account waarvan de Inbox eerst staat (onder de hoofding Inkomend in de zijbalk van Mail); je kunt de volgorde van deze lijst veranderen door inkomende postbussen omhoog of omlaag te verschuiven.
Om te begrijpen waarom dit een ernstig probleem kan zijn, denk je maar aan een gebruiker met drie verschillende POP-accounts, bijvoorbeeld een thuisaccount, een werkaccount en een familie-account. Berichten van al die accounts worden in verschillende lokale postbussen opgeslagen, eventueel automatisch door middel van regels. Wanneer één van deze berichten moet worden beantwoord, moet de gebruiker er van op aan kunnen dat het antwoord zal worden verstuurd van dezelfde account waarin hij het bericht heeft ontvangen en dit zonder enige tussenkomst. Dat was vroeger zo, maar nu niet meer. Uitgaande berichten kunnen worden gemist of verwijderd omdat zij van de verkeerde account komen, berichten kunnen gaan van een zakelijke naar een persoonlijke account, etc.
Ik heb geen idee waarom Apple dit veranderd heeft, of het opzettelijk is, waarom het niet gedocumenteerd is en of het in de toekomst weer zal worden veranderd. Omdat de verandering misschien wel opzettelijk is en om een reden die ik gewoon niet begrijp, durf ik dit geen bug te noemen. Maar de verandering betekent in ieder geval wel meer moeite voor de gebruikers en al bij al is het voor mij geen goede stap. Als je het met me eens bent, kies dan "Mail > Reageer op Mail…" en laat Apple weten wat je denkt. We kunnen alleen maar hopen dat Apple dit verandert in een update van OS X.
Intussen moet ik met spijt bekennen dat ik geen manier ken om het gedrag van Mail te herstellen naar de toestand van voor Mountain Lion. Wanneer je een account kiest in het popupmenu "Account van geselecteerde postbus", dan blijft het gedrag van Mail vrij consistent, al past het misschien niet bij wat je wil. Wanneer je alleen met server-postbussen werkt, als je dat kan, dan vermijd je het ergste deel van het probleem. Afgezien van deze zwakke suggesties, kan ik alleen maar aanraden om de verandering in gedachten te houden en om waakzaam te blijven wanneer je berichten verstuurt.
Nog een laatste tip, met dank aan Christopher Stone op de TidBITS Talk-mailinglijst: in Mountain Lion kun je met een toetscombinatie de Van-account van je nieuw bericht veranderen; dit is misschien iets gemakkelijker dan met de muis of trackpad de account kiezen in het popupmenu "Van". Om een toetscombinatie toe te wijzen, open je het paneel Toetsenbord in Systeemvoorkeuren, klik op Toetscombinaties en kies dan Toetscombinaties voor programma's. Klik op de knop + (plus) en kies Mail in het popupmenu Programma. In het veld Menunaam, typ de exacte naam en e-mailadres zoals ze staan in het popupmenu "Van", bijvoorbeeld:
Joe Kissell
Voer de toetscombinatie in die je wil gebruiken en klik op "Voeg toe" en herhaal dit indien nodig voor meerdere accounts. De volgende keer dat je een nieuw bericht maakt en eraan denkt dat je de Van-account wil veranderen, druk je op overeenkomstige toetscombinatie.
Lees reacties op dit artikel of plaats er een | Tweet dit artikel
In het recent uitgebrachte OS X 10.8 Mountain Lion heeft Apple iets gedaan waarvan ik dacht dat ze het nooit zouden doen: ze keerden op hun schreden terug. Min of meer. Ze sloegen acht op de bezwaren van gebruikers tegen een belangrijke eigenschap van 10.7 Lion en ondernamen stappen om aan die bezwaren tegemoet te komen. Ze hebben de eigenschap niet weggehaald (dat zou, denk ik, te veel gevraagd zijn), maar ze veranderden de interface en gaven de gebruiker meer keuzes en mogelijkheden.
In dit artikel zal ik schetsen wat op dit vlak de verschillen zijn tussen Mountain Lion en Lion en waarom ik persoonlijk meer van Mountain Lion dan van Lion houd. Lees voor meer details en voor veel meer over Mountain Lion, mijn boek, "Take Control of Using Mountain Lion".
De Lion-situatie -- De functionaliteit in kwestie, die Apple het Modern Document-model noemt, is de manier waarop documenten worden opgeslagen en behandeld door programma's die zijn geschreven om op juiste wijze gebruik te maken van bepaalde technologieën die werden geïntroduceerd in Lion:
"Auto Save", het epicentrum van het Modern Document-model, houdt in dat documenten die worden geopend in deze programma's automatisch worden opgeslagen terwijl je eraan werkt. Je kan nog steeds bestanden handmatig opslaan maar je kan dus ook, theoretisch, in een document werken binnen Modern Document-model-programma's zonder ooit handmatig op te slaan, met uitzondering wellicht van het allereerste begin als je een naamloos bestand moet opslaan om het een naam en een plaats te geven in de mappen-hiërarchie.
In Lion zal het zwarte stipje nooit verschijnen in de rode sluit-knop van het documentvenster, dat zo bekend is bij gebruikers van voorgaande versies van het Mac OS X-systeem. Een document is nooit "vuil" (onopgeslagen) want het wordt altijd automatisch opgeslagen. Bovendien zal om dezelfde reden, zodra een document wordt gesloten, nooit een "Wilt u de veranderingen opslaan?"-dialoogvenster verschijnen. (Er is één bijzondere situatie waarbij zo'n dialoogvenster wel verschijnt in Lion maar dat beschrijf ik zometeen.) Het woord "Bewerkt" verschijnt in de titelbalk van een document dat aangepast is sinds het werd geopend of handmatig werd opgeslagen maar veel gebruikers vinden deze hint niet sterk genoeg.
"Resume" is de mogelijkheid die een programma heeft om als het wordt opgestart, automatisch alle vensters (met name van documenten) die open stonden toen het programma de vorige keer draaide, wederom te openen. Lion geeft de mogelijkheid dit gedrag systeem-breed aan en uit te schakelen of per individueel programma als het afgesloten wordt (hoewel in sommige gevallen, zoals ik aangaf in "Lion zombie document-mysterie opgelost", 23 mei 2012, het venster van een programma bij het opstarten toch weer in de oude staat wordt geopend ook al had je ingesteld dit niet te doen). Resume is dicht geïntegreerd met Auto Save. Als beide werken merk je hoe Mac OS X duidelijk iOS imiteert want daar zou men idealiter het verschil niet moeten merken tussen het overschakelen naar een programma of het programma opstarten nadat het was afgesloten.
Als je in Lion een Modern Document-model-programma afsluit terwijl er nog een naamloos document openstaat, dan wordt dit document automatisch opgeslagen (Auto Save) en ook automatisch heropend wanneer het programma weer wordt opgestart (Resume), los van je Resume-instellingen. Maar als je een nieuw naamloos document handmatig sluit (met "Archief > Sluit" of door op de sluit-knop in het venster te klikken), verschijnt er een dialoogvenster ("Wilt u de gemaakte wijzigingen… bewaren?") waarin je het naamloze document kan opslaan of de inhoud voor eens en voor altijd kan verwijderen.
"Versions" is het vermogen van het systeem om de huidige staat van een automatisch opgeslagen document bij te houden zodat je later terug kan gaan naar die staat. Voor een deel wordt de staat automatisch bijgehouden. Bovendien wordt, als een document in Lion eenmaal is opgeslagen (zodat het niet langer een nieuw naamloos document is), het "Archief > Bewaar"-menu vervangen door "Archief > Bewaar een versie"; het document wordt natuurlijk voortdurend automatisch opgeslagen maar door "Bewaar een versie" te kiezen, wordt er niet alleen opgeslagen maar die specifieke staat van het document wordt ook vastgelegd in de Versions-database.
In Lion heb je eigenlijk alleen toegang tot de Versons-database door middel van "Archief > Vorige versie"-menu dat een Time Machine-achtige bediening toont met alle opgeslagen versies van het document. Een specifieke staat van een document, de staat van toen deze het laatste geopend of opgeslagen was, kan ook toegankelijk zijn vanuit het titelbalk-menu van het document.
Het "Archief > Bewaar als"-menu waar gebruikers al sinds Systeem 6 (of eerder) aan gewend zijn, is er niet in Lion. In het geval van een nieuw naamloos bestand is het ook overbodig want "Archief > Bewaar" heeft dezelfde functie, te weten het geven van de mogelijkheid om een naam en een plaats in een map aan een bestand te geven. In het geval van een eerder opgeslagen document, is dit commando vervangen door "Archief > Dupliceer", dat de huidige staat van een bestand kopiëert naar een nieuw naamloos bestand zonder het originele bestand te sluiten. De gebruiker kan dan dit nieuwe document opslaan (en het een naam en een plek in een map geven).
Het probleem met Lion -- Het Moderne Document-model van Lion stond voor een revolutie in de manier waarop gebruikers werken met documenten in een programma, maar veel gebruikers waren hier niet zo blij mee. Het ont-leren van de gewoonte om er steeds even aan te denken dat je een document opslaat (zodat het niet verloren gaat als het programma crasht) was gemakkelijk. Het echte probleem lag meer in de kleine ongelukjes.
Wie heeft er nooit een programma afgesloten met het idee er niets aan veranderd te hebben, om vervolgens toch een "Wilt u deze aanpassingen opslaan?"-dialoog te krijgen? Waarna bleek dat je wel degelijk iets veranderd had, per ongeluk. Je dacht dat je iets kopieerde, maar eigenlijk knipte je een stuk tekst. Of er was een kat die lichtjes over het toetsenbord had gelopen terwijl er een belangrijke alinea geselecteerd stond. Die waarschuwingsdialoog was je redding, waardoor je de onbedoelde aanpassingen toch nog kon cancelen. In Lion is er geen dialoog of waarschuwing: al je toevallige veranderingen worden opgeslagen zonder dat je er iets van merkt en mogelijk geheel tegen je zin.
Kortom, Auto-save in Lion werkte volgens gebruikers als valkuil, want de nieuw ontworpen functie zou te gemakkelijk leiden tot de problemen die deze juist moest voorkomen, namelijk het per ongeluk wissen van data. De data waren dan wel niet echt verloren, aangezien de "Versies"-database een bruikbare oudere versie zou bevatten, maar het terugvinden van die versie in de onhandige Time Machine-achtige interface was niet eenvoudig. En wat zou er gebeuren als je na het opslaan van een verkeerde aanpassing (die je niet eens gemerkt had) het document afsloot en pas dagen (of zelfs weken) later weer opende? Zou je dan, gruwend en in totale verwarring, iets aan "Versions" hebben om te begrijpen wat er gebeurd was? Zou de database je kunnen helpen aan een document in de juiste staat? De hele situatie leek op de omgekeerde wereld: je maakt eerst per ongeluk een grote fout, die je pas later ontdekt (als je geluk hebt) en dan moet je eindeloos gedoe doormaken om het probleem te repareren. In dezelfde situatie vóór Lion zou je allang gewaarschuwd zijn en had je het foute document helemaal niet opgeslagen.
En dan is er de situatie waarin je aan het experimenteren bent. Wie heeft nooit met opzet wat gespeeld, geëxperimenteerd met teksten in een document, wetend dat het toch geen kwaad kon? Je kon uiteindelijk eenvoudig het bestand afsluiten zonder iets op te slaan, of de aanpassingen opslaan in een ander document met "Opslaan als…". En dan komt Lion en nu worden al je experimenten opeens opgeslagen, maar stiekem achter je rug, tegen je zin zelfs. Lion staat experimenten natuurlijk niet echt in de weg: het enige dat je hoeft te doen is het kiezen van "Bestand > Dupliceer" en je werkt in een niet-opgeslagen versie van je document. Dit document kan je uiteindelijk wel gewoon afsluiten zonder het op te slaan. Maar ook hier lijkt het verkeerd-om, want je moet er aan denken om "Bestand > Dupliceer" te kiezen voordat je aan het experimenteren slaat, iets wat je gemakkelijk vergeet. Of je realiseert je misschien niet meteen dat je de nieuwe aanpassingen toch niet wilt, maar dan is het al te laat.
Mountain Lion biedt de reddende hand -- Er zijn twee opties die Mountain Lion naar het Moderne Documentenmodel brengen. Je vindt beide als afvinkvakjes in het "Algemeen"-paneel van de Systeemvoorkeuren en je gebruikt ze om te bepalen wat programma's moeten doen als je documenten sluit. Er zijn ook wat nieuwe menu-onderdelen, maar laten we beginnen met de eerste:
"Vraag of wijzigingen moeten worden bewaard bij het sluiten van documenten". Als hier geen vinkje staat gedraagt Mountain Lion zich net als Lion. Als er wel een vinkje staat is het gedrag van Mountain Lion meer als dat van Snow Leopard en eerder: de "vuile" stip in de sluitknop is er weer! Er is weer een waarschuwing als je een "vuil" document wilt afsluiten! Dat betekent dat onder Mountain Lion de kansen kleiner zijn dat je per ongeluk veranderingen aanbrengt die je eigenlijk helemaal niet wil.
Onthoud wel dat dit niet betekent dat het automatisch bewaren is uitgeschakeld. Achter de schermen vindt dit nog steeds plaats. De waarschuwing vraagt of je je veranderingen wilt opslaan en de standaardknop is "Bewaren" maar je document is in feite al opgeslagen en in feite kies je voor terugkeren naar de oude status (die zich natuurlijk nog steeds in de versies-database bevindt). Automatisch bewaren is dus nog steeds actief, maar de interface laat het voorkomen dat dat niet zo is.
"Sluit vensters bij het stoppen van een programma". Dit is verraderlijk, omdat er feitelijk twee dingen gedaan worden met een enkele actie: (1) het bepaalt of in het gehele systeem documenten automatisch moeten heropend en (2) het bepaalt of met het sluiten van een programma ook de documenten moeten worden gesloten.
Daarom even het volgende voorbeeld: stel dat er geen vinkje staat bij deze optie. Als je dan een programma sluit met geopende documenten, worden de vensters gesloten zonder waarschuwing, ook als je ze wel aangepast hebt. Je zegt dus eigenlijk met het niet zetten van een vinkje: "Het sluiten van een programma is iets anders dan het sluiten van de afzonderlijke vensters van documenten. Als ik zeg stop bedoel ik meteen stoppen en ik wil niet wachten". Dit is zelfs waar als er wel een vinkje staat bij de eerste optie, omdat volgens de tweede optie het stoppen van een programma iets anders is dan het sluiten van documenten! In plaats hiervan wordt de status van deze documenten automatisch bewaard en worden de documenten de volgende keer dat het programma gestart wordt automatisch geopend. (Merk op dat bij een vinkje bij de eerste optie, de "vuile" staat van documenten wordt geopend. De "vuile" stip is dan nog steeds zichtbaar.)
Als er wel een vinkje staat bij de tweede optie dan neemt de eerste optie als het ware de macht over: als de eerste vink er dan wel staat zul je bij het stoppen van een programma met een enkel "vuil" document de vraag zien of je de veranderingen op wilt slaan en bij het stoppen van een programma met meerdere "vuile" documenten een oude bekende dialoog zien: "Je hebt … documents met veranderingen die niet opgeslagen zijn. Wil je deze zien voordat het programma gesloten wordt?"
Bovendien worden bij het inschakelen van de tweede optie de documenten niet automatisch heropend. Maar stel nu eens dat je de Optie-toets ingedrukt houdt bij het sluiten. Dan werkt alles alsof dat vinkje er niet stond en je zegt: "Ogenblikkelijk stoppen!" Dat gebeurt dan ook, ook als het eerste vinkje er wel staan, en zelfs als sommige documenten "vuil" zijn (en de eerstvolgende keer dat je het programma opent deze documenten automatisch heropend worden in hun "vuile" status.
Aanvullend biedt Mountain Lion's Moderne Document-model de volgende menukeuzes:
"Archief > Bewaar" is nu altijd "Archief > Bewaar";. Het veranderd niet naar "Archief > Bewaar een versie". Natuurlijk, het bewaren van een eerder bewaard document, bewaard nog steeds een versie maar het onveranderde menu maakt de zaak eenvoudiger.
In aanvulling op "Archief > Dupliceer" van Lion is de menukeuze "Archief > Bewaar als…" terug. In feite is het een alternatief voor de eerstgenoemde (optie-klik op "Archief" en het te zien). Dit geeft gebruikers de keuze om te werken op een manier die zij makkelijk en toepasselijk vinden. "Archief > dupliceer" maakt een kopie in een naamloos bestand en laat het huidige bestand open achter het nieuwe bestand. "Archief > Bewaar als…" is vergelijkbaar met pre-Lion-systemen, het laat je een kopie maken van de huidige versie op een andere locatie met een nieuwe naam, waar het venster de kopie laat zien in plaats van de huidige versie.
"Archief > Vorige versie" (in plaats van Lion's "Archief > Eerder document") is nu een menustructuur: de onderdelen hangen af van de omstandigheden en kunnen bevatten "Laatst geopend", "Laatst bewaard" en "Blader door alle versies…", waarmee de focus wordt gelegd op de meeste gebruiksscenario's en verduidelijkt je opties.
Ten slotte zijn er twee compleet nieuwe menu-keuzes in Mountain Lion. Met "Archief > Wijzig naam…" geef je een document een andere naam op dezelfde plek. Met "Archief > Verplaats naar…" kan je een document verplaatsen naar een andere map. Dit zijn acties die je voorheen vanuit de Finder deed. Nu kun je het direct vanuit de applicatie doen terwijl het document nog open is. Beide menukeuzes zijn zo nuttig dat je je afvraagt hoe dat we zonder hebben kunnen leven in eerdere systeem versies.
Al deze menukeuzes zijn beschikbaar in het Archief-menu maar ook in het titelbalk-menu, behalve, vreemd genoeg, "Bewaar", wat dus een tweederangsplek heeft gekregen
(ik moet nog een verandering melden. In Lion, ging een document op slot als ik het voor een bepaalde tijd niet bewerkte, zeg twee weken. In Mountain Lion is dit automatische slot opgeheven. Je kan nog steeds een document op slot zetten vanuit het titelbalk-menu, maar dit is niks anders dan van uit de Finder waar je altijd al de mogelijkheid had een bestand op slot te zetten.)
Conclusie -- Persoonlijk vind ik dat deze wijzigingen Mountain Lion een stuk werkbaarder en acceptabeler maken dan Lion en ik ga er van uit dat veel gebruikers er hetzelfde over denken. Ik ben vooral onder de indruk van de bereidheid van Apple om gebruikers zelf te laten kiezen, iets waar ik in het verleden al vaak om heb gevraagd. De twee aanvinkvakjes in het voorkeurvenster Algemeen stellen gebruikers in staat er voor te kiezen om Mountain Lion zich te laten gedragen als Lion, dan wel om documenten te behandelen zoals daarvoor gebruikelijk was, als ze daar beter mee uit de voeten kunnen. Zo vind ik het ook een voordeel dat ik kan kiezen tussen "Archief > Dupliceer" of "Archief > Bewaar als…", afhankelijk van waar ik mee bezig ben. En ik ben helemaal te spreken over de manier waarop Apple de onderdelen van het menu Archief door elkaar heeft gehusseld, met name de nieuwe onderdelen "Wijzig naam" en "Verplaats naar…".
Merk overigens wel op dat ik niet beweer dat ik helemaal gelukkig ben met het Moderne Document-model. Feitelijk, als ik heel eerlijk ben, vind ik het hele concept van "Auto Save" een grote vergissing, een volledig misplaatste fictie dat het bureaublad vergelijkbaar is met iOS. De diep ingebakken misvatting wordt goed geïllustreerd aan de hand van wat er gebeurt als je een bestand bewerkt op een geactiveerde netwerkschijf: dan krijg je Auto Save zonder Versions en zelfs Apple geeft toe dat dat tot problemen kan leiden. Zie het artikel van Adam Engst over dit onderwerp: "Pas op voor de bug met netwerkschijven (en niet-HFS+) met Versies van Lion" (8 september 2011).
Verder levert de aanwezigheid in Mountain Lion van "Documenten in de Cloud" (de mogelijkheid van sommige applicaties om documenten zodanig op te slaan dat iCloud ze kan synchroniseren) extra complicaties op. Het zou te ver voeren om hier op alle details in te gaan, maar het is in ieder geval zo dat een programma dat iCloud-ondersteuning biedt andere Moderne Document-model-waarschuwingen en Open en Bewaar-dialoogvensters produceert dan een programma dat geen weet heeft van iCloud. Daarmee hebben we een drievoudige "Balkanisering" van het bureaublad gekregen: applicaties die niet meedoen met het Moderne Document-model, applicaties die dat wel doen maar geen iCloud-ondersteuning bieden en applicaties die beiden doen. En al deze typen programma's zien er anders uit en gedragen zich anders (in mijn boek "Take Control of Using Mountain Lion" ga ik daar dieper op in).
Nu ik toch aan het klagen ben wil ik ook nog wel even doorzeuren over mijn bezwaren tegen dat tweede aanvinkvakje: "Sluit vensters bij het stoppen van een programma". Zoals ik al zei, dit doet eigenlijk twee dingen. Het zet op systeemniveau Resume aan of uit en het bepaalt of bij het afsluiten van een programma de documentvensters onder de rubriek van het eerste, "Vraag of wijzigingen moeten worden bewaard bij het sluiten van documenten"-aanvinkvakje. Maar die twee zaken, hoewel verwant, zijn zeker niet identiek en de naam van het aanvinkvakje dekt van geen van beide opties de lading. Dit heeft tot gevolg dat het effect van dit aanvinkvakje niet bepaald begrijpelijk is. Zelfs de doorgaans zo grondige John Siracusa lijkt het niet helemaal door te hebben, getuige zijn behandeling ervan in zijn Technical review of Mountain Lion en ikzelf vergat ook een deel van het verhaal te vertellen in mijn Take Control-boek.
En Apple heeft ook het eerste aanvinkvakje niet helemaal correct geïmplementeerd. Het bijschrift luidt: "Vraag om wijzigingen moeten worden bewaard bij het sluiten van documenten", maar als je een document opent en bewerkt en vervolgens "Archief > Bewaar als…" kiest (met aan zekerheid grenzende waarschijnlijkheid het meest voorkomende gebruik van "Bewaar als"), wordt in feite het originele document gesloten zonder dat je gevraagd wordt of je je wijzigingen wilt bewaren. Het nieuwe bestand bevat de niet-geaccordeerde wijzigingen, wat op zich zinvol is, maar het oude bestand ook en dat is in tegenspraak met de belofte om gevraagd te worden of wijzigingen behouden moeten worden. Merkwaardigerwijs deed Lion het hier beter dan Mountain Lion: als je in Lion "Archief > Dupliceer" kiest bij een document met wijzigingen, krijg je een dialoogvenster te zien waarin je wordt gevraagd of je vooraleer het duplicaat gemaakt wordt de wijzigingen ongedaan wilt maken. In Mountain Lion krijg je dat dialoogvenster niet meer te zien.
Maar dat mag allemaal wel zo zijn, alles bij elkaar genomen vind ik dat de wijzigingen in het Moderne Document-model in Mountain Lion positief, slim, en bijzonder belangrijk zijn. Ik zou nog liever zien dat je Auto Save helemaal uit kunt zetten, maar als we er even van uitgaan dat Apple nooit zover zal gaan, dan moet gezegd worden dat ze zich uitgeput hebben om Auto Save aanvaardbaar te maken voor zoveel mogelijk gebruikers, zelfs al hebben ze nog wel een paar steekjes laten vallen. Ik begrijp dan ook de houding van David Pogue niet zo goed, die in zijn artikel in de New York Times waarin hij Mountain Lion aankondigt, Lions Auto Save terecht "verwarrend" noemt, maar vervolgens de wijzigingen in Mountain Lion in het Moderne Document-model afdoet als een paar gewijzigde menu-onderdelen en daar een negatief oordeel over velt. De betreffende wijzigingen zijn voor mij de belangrijkste reden om Mountain Lion te verkiezen boven Lion en zouden volgens mij zelfs gebruikers die de overstap van Snow Leopard naar Lion aan zich voorbij lieten gaan (waartoe ik mezelf in feite ook reken) om een overstap naar Mountain Lion te overwegen.
Lees reacties op dit artikel of plaats er een | Tweet dit artikel
Nisus Writer Pro 2.0.4 en Express 3.4.3 -- Hoewel beide tekstverwerkers kortgeleden nog flink herzien werden heeft Nisus Software Nisus Writer Pro 2.0.4 en Nisus Writer Express 3.4.3 uitgebracht om een paar nieuwe problemen op te lossen. Als je OS X 10.8 Mountain Lion draait is een vastloper aangepakt die optrad bij een rechterklik op de stijlenlijst. Er wordt bovendien nu juist afgebroken voor andere talen dan Engels, een probleem opgelost met het zoomen in de Afdrukken-dialoog, problemen opgelost met verwijzingen naar bestanden en een probleem opgelost waar bij het zoomen in de Draft modus het scherm flikkerde. In het geval van Nisus Writer Pro lost versie 2.0.4 een probleem op met het exporteren van documenten met speciale karakters naar EPUB, een vastloper aangepakt bij het kopiëren en plakken van meerdere secties waarnaar gerefereerd wordt in de inhoudsopgave en een probleem met het veranderen van de kleur van de rand van een paragraaf in een stijl. (Voor Nisus Writer Pro: $ 79 nieuwe versie, gratis update, 159 MB, toelichting. Voor Nisus Writer Express: $ 45 nieuwe versie, gratis update, 51 MB, toelichting.)
Reacties - Nisus Writer Pro 2.0.4 and Express 3.4.3
DEVONthink en DEVONnote 2.4 -- DEVONtechnologies heeft alledrie de edities van DEVONthink (te weten Personal, Pro en Pro Office) en DEVONnote bijgewerkt naar versie 2.4, waardoor ze compatibel zijn met de nieuwe functies in OS X 10.8 Mountain Lion. De nieuwe uitgaven hebben ondersteuning voor met name Berichtencentrum, kunnen omgaan met Gatekeeper en hebben nu een Deel-knop voor het delen van bestanden via iMessage, Mail, Twitter, Facebook en AirDrop (en om ze toe te voegen aan Safari's Leeslijst). Door de toegevoegde 64-bit ondersteuning zijn de grootten van de databases nu nog slechts beperkt door de hoeveelheid beschikbaar geheugen en de prestaties van je Mac. Alledrie de versies van DEVONthink kunnen nu scans importeren van scanners en camera's die werken met Fotolader (inclusief iOS-apparatuur). Voorheen was deze functie alleen beschikbaar in de Pro Office versie. (Alle updates zijn gratis. DEVONthink Pro Office, $ 149,95 nieuw; DEVONthink Professional, $ 79,95 nieuw; DEVONthink Personal, $ 49,95 nieuw, toelichting; DEVONnote, $ 24,95 nieuw, toelichting)
Reacties - DEVONthink and DEVONnote 2.4
TextExpander 4.0.1 -- Smile heeft TextExpander 4.0.1 uitgebracht, een onderhoudsupdate voor het onlangs geüpdatete hulpprogramma voor afgekort typen met een reeks oplossingen en verbeteringen. Deze versie herstelt de transparantie in het menubalksymbool, maakt het label kruisvakje aanklikbaar voor optionele sectie-invullingen en updatet de hulpsectie voor de Japanse en de Italiaanse lokalisering. Verder eindigen gelijkheidsafkortingen in de Symbol-groep nu op twee gelijk-aantekens (bijvoorbeeld ">=="). Daarnaast zijn er nog veel andere niet nader genoemde kleine oplossingen en verbeteringen. ($ 34,95 nieuw met een korting van 20 procent voor TidBITS-leden, $ 15 upgrade (gratis voor aankopen na 15 januari 2012), gratis update, 8,5 MB)
Reacties - TextExpander 4.0.1
HyperCard werd 25 jaar geleden uitgebracht en daarom besteden we in ExtraBITS deze week aandacht aan linkjes in Twitter met herinneringen aan het programma. Daarnaast kijken we naar de nieuwe Power Nap-functie van Mountain Lion en we horen nog wat meer over het hacken van Mat Honan's iCloud-account (wat op deze specifieke manier niet meer zou moeten kunnen gebeuren).
Mijmeren op de 25-ste verjaardag van HyperCard -- Op 11 augustus 1987, op de Macworld Expo in Boston, bracht Apple het "Software Bouwpakket" HyperCard uit. Het programma verdween al jaren geleden van het toneel, maar toentertijd bracht het grote veranderingen in de levens van Mac-gebruikers. Veel mensen konden nu ideeën publiceren die anders nooit voor het voetlicht gekomen waren, waaronder misschien ook TidBITS. Wij brachten onze eerst 99 afleveringen uit in HyperCard-vorm, waarbij iedere serie artikelen automatisch geïmporteerd werd in een doorzoekbare database. Zonder de opwinding die het werken met zo'n geheel nieuw formaat met zich meebracht was TidBITS misschien ergens in de beginfase gestrand. In deze zoekresultaten uit Twitter kan je lezen wat anderen hierover te melden hebben. En kijk op je iPad ook even bij Infinite Canvas!
Dan Frakes verklaart Power Nap -- Mountain Lion biedt een nieuwe functie genaamd Power Nap, maar bijna niemand zal deze al hebben kunnen zien, aangezien hij alleen op een paar nieuwe Apple-laptopmodellen werkt. Een korte samenvatting: Power Nap maakt het mogelijk dat ondersteunde Macs voor korte tijd uit slaapstand ontwaken om een back-up via Time Machine te maken, om op nieuwe berichten te checken met Mail.app, om te kijken of er nieuwe Berichten zijn en om iCloud-gerelateerde gegevens te updaten: agenda-items, contacten, herinneringen, notities, iCloud-documenten en foto's in Photo Stream. Onze vriend Dan Frakes van Macworld legt onder andere uit wat Power Nap allemaal kan, hoe je het programma gebruikt en waarom het alleen op een klein aantal nieuwe modellen werkt.
Hoe beveiligingsmissers bij Apple en Amazon zorgden dat Mat Honan slachtoffer van hacking kon worden -- Mat Honan, schrijver voor Gizmodo, heeft een flink artikel geschreven voor Wired waarin hij precies beschrijft hoe missers bij de beveiliging van Amazon (waarbij deel van een creditcardnummer getoond werd) en Apple (waarbij een identiteitscontrole werd gedaan met deze Amazon-gegevens en andere openbare informatie) zorgden dat een groot deel van zijn digitale leven gehackt kon worden. Het levert fascinerend leesvoer op en wij halen er voorlopig de moraal uit dat je echt absoluut moet werken met lokale back-ups van al je gegevens (zowel die van je Mac, iPhone als die in de cloud). Mat had dat niet gedaan en hoewel de scheur in zijn "leven online" maar tijdelijk was, geldt dat niet voor de onvervangbare gegevens die op zijn Mac stonden toen die op afstand volledig gewist werd.
Apple en Amazon wjzigen hun beveiligingsbeleid -- Nog lang niet alle details zijn bekend, maar Wired meldt dat de betrekkelijk eenvoudige hack waarmee Mat Honans digitale bestaan van afstand overgenomen kon worden niet meer mogelijk is, nadat zowel Amazon als Apple hun beveiligingsbeleid met betrekking tot gebruikers-accounts gewijzigd hebben, in ieder geval tijdelijk. Hoe het beleid zich op termijn zal ontwikkelen is onbekend, maar dat er wat moest veranderen was wel duidelijk.
Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering