Standalone web apps in OSX met Fluid

Bij Sterc maken we steeds meer gebruik van web applicaties. E-mail via Google Apps Gmail, uren/offertes/facturen via Harvest, planning via Google Calender, CRM via Highrise, collaboration via Basecamp en RSS via Google Reader. Waarschijnlijk ben ik er dan nog een paar vergeten, maar “you get the point”.

Sinds een paar maanden heb ik al deze web applicaties als standalone applicaties in mijn OSX dock staan:

Wat je ziet zijn icoontjes in de OSX dock voor een aantal web apps. Deze apps draaien stand alone in een gestripte versie van Safari 3 (nog niet 4 dus) Webkit (thanks Erik) door middel van Fluid. Alle toolbars zijn weg, je ziet alleen de app zelf, waardoor het net is alsof je in een gewone native applicatie zit te werken.

Het leuke hieraan is dat Fluid een bij een aantal web apps ook zaken registreert en weergeeft in de dock, zoals: ongelezen e-mails in Gmail en ongelezen RSS berichten in Google Reader. Voor WordPress is tegenwoordig ook al een plugin, Fluid Enabler, die ervoor zorgt hoeveel ongelezen comments en dergelijke in je dock worden weergegeven.

Fluid heeft ook zijn nadelen:

  • Naarmate je Fluid langer gebruikt worden apps trager (cache legen wil dit wel eens verhelpen)
  • Soms kun je niet uploaden via een Fluid app (het bladeren-venster verschijnt niet altijd)
  • Soms erg instabiel (random crashes)
  • Niet erg actief development team

Een goede tip is het uitschakelen van “url restrictions”, door alle URL’s toe te voegen, zie onderstaande screenshot:

URL Restrictions

Hieronder nog enkele in-app screenshots:

Het is hopen op Safari 4 integratie in Fluid, dan zou het een stuk leuker worden. Fluid is al snel van zichzelf, maar de Safari 4 engine zou het allemaal nog een stukje aangenamer en misschien ook wel stabieler maken. Desondanks blijf ik Fluid met plezier gebruiken en typ ik deze blogpost dan ook in een Fluid app.

Lees meer over Standalone web apps in OSX met Fluid

Voorkom te snelle indexatie door zoekmachines!

Als programmeur ben ik iemand die op details let. Ik kan User Interfaces (UI’s) van veel gebruikte programma’s bijna dromen en klik me elke dag een slag in de rondte in die UI’s. Het liefst gebruik ik natuurlijk sneltoetsen voor al die klik-handelingen. Alt-Tab is de uitvinding van de eeuw. Door de snelheid in het werkproces wil het nog wel eens gebeuren dat je té snel dingen doet.

Enkele voorbeelden die veel programmeurs vast wel eens meegemaakt hebben:

  • Op een server werken en snel een bestand bewerken, opslaan, sluiten en vervolgens erachter komt dat je toch iets te snel was en een bug veroorzaakt hebt (ontbrekende punt-komma, haakjes die missen, etc.);
  • Op een server een CSS bestand wijzigen en je afvragen waarom er niets op de site verandert, terwijl je toch echt je cache hebt geleegd. Na 10 minuten verwensingen slingeren naar je favoriete browser kom je erachter dat je verbonden bent met de verkeerde server en onbewust een andere site aan het wijzigen bent;
  • Tussendoor even aan een blog post werken en per ongeluk op ‘Publiceren’ klikken, in plaats van ‘Concept opslaan’;

Punt 1 & 2 zijn slordigheidjes waar je vrij weinig aan kan doen, behalve focussen. Punt 3 overkomt mij geregeld tijdens het bloggen, vorige week nog. Gevolg: je halve artikel staat binnen 5 minuten in Google, met een verkeerde omschrijving en een lading spelfouten.

Voor dit probleem heb ik een eenvoudige oplossing: maak twee accounts aan bij je favoriete blogging platform/CMS.

Er is meer…

Lees meer over Voorkom te snelle indexatie door zoekmachines!