Πολυκαναλικότητα: Η νέα Απαίτηση

Ένας από τους πιο δημοφιλείς όρους που συναντά κανείς πλέον στο χώρο των εφαρμογών/υπηρεσιών προστιθέμενης αξίας είναι αυτός του «Unified Self-Service”, που ουσιαστικά απαντά στην ανάγκη για «οργανωμένη» διάθεση της υπηρεσίας μέσα από πολλά κανάλια ανά πάσα στιγμή. Η τάση λοιπόν είναι για:

  • μια εφαρμογή
  • πολλά κανάλια αλληλεπίδρασης με τον τελικό χρήστη
  • ιδανικά το ίδιο περιβάλλον ανάπτυξης για όλα τα κανάλια
  • συγκεντρωτικές καταγραφές (logs)
  • συγκεντρωτικά στατιστικά στοιχεία για τη χρήση της εφαρμογής (business intelligence/analytics)
  • ανάπτυξη από την ίδια ομάδα προγραμματιστών
  • Τα παραπάνω δεν σημαίνουν απαραίτητα ότι η εμπειρία χρήσης της εφαρμογής είναι ίδια για όλα τα κανάλια αλλά προσαρμόζεται ώστε να εκμεταλλεύεται τις δυνατότητες και να καλύπτει τις αδυναμίες του κάθε καναλιού.

    Όσο για τα κανάλια; Πλέον είναι πολλά, όπως φαίνεται στο παρακάτω σχήμα:

    Και να σκεφτεί κανείς ότι το παραπάνω σχήμα είναι …ενδεικτικό μιας και μπορεί κανείς να προσθέσει τα μη ευρέως αυτοματοποιημένα κανάλια (π.χ. email, fax) αλλά και τις …εξειδικεύσεις του κάθε καναλιού, όπως mobile web, tv web (πχ βλ GoogleTV), browser softphone κλπ

    Τεχνολογία και ..τέχνη

    Η χτεσινοβραδινή κουβέντα με την παρέα (την ώρα της καθιερωμένης μπυρο..κατάνυξης) σχετικά με εφαρμογές στο χώρο της ηλεκτρονικής σχεδίασης (δεν έλλειψαν αναφορές σε Spice, Mentor Graphics κλπ κλπ) , μου θύμισε ότι έχω απομακρυνθεί πάρα πολύ (έως ..ανεπιστρεπτί;!) από το συγκεκριμένο τομέα…

    Ας το προσεγγίσω λίγο από τη μεριά της ..τέχνης μπας και αργότερα επανέλθω κι εμβαθύνω πιο πολύ:

    Περισσότερα έργα τέχνης εδώ.

    Η ανάκαμψη των φωνητικών εφαρμογών

    Μέχρι τα μέσα -τουλάχιστον, για τα δεδομένα της Ελλάδας- της περασμένης δεκαετίας τα κλειστά (συνήθως APIs για τη δημιουργία φωνητικών και τηλεφωνικών γενικότερα αλληλεπιδραστικών εφαρμογών αρνούνταν πεισματικά να παραδώσουν τη σκυτάλη στο ανοιχτά πρότυπα VXML (πλέον στην έκδοση 3.0), CCXML, GRXML κλπ.

    Και παρόλο που αρκετοί ήθελαν να δημιουργήσουν τέτοιες εφαρμογές ως μια από τις βασικές εκδοχές του ubiquitous computing (μιας και το mobile web ήταν ακόμη στα σπάργανα), χάθηκε η ευκαιρία ο χώρος να ακολουθήσει τους ρυθμούς εξέλιξης των εφαρμογών web. Βέβαια, με δεδομένες τις δυνατότητες των σημερινών συσκευών δεν μιλάμε για αντικατάσταση των εφαρμογών ιστού αλλά για συμπλήρωσή τους για εκείνες τις περιπτώσεις που ακόμη και η περιοριστική παροχή πληροφοριών με γραμμικό τρόπο είναι πιο κατάλληλη (ή η μόνη διαθέσιμη μέσω της κλήσης ενός τηλεφωνικού αριθμού κι από την πιο απλή τηλεφωνική συσκευή).

    Οι λόγοι της υστέρησης, πέρα από τον παραπάνω, είναι πολλοί:

  • κλειστή φύση των εφαρμογών τηλεφωνίας αλλά και της επικοινωνίας με μηχανές αναγνώρισης ομιλίας/σύνθεσης φωνής που ελέγχονταν από λίγες μεγάλες εταιρείες
  • διαρκώς νέα APIs και εργαλεία (γραφικά ή μη) που πρέπει να υιοθετηθούν από τους προγραμματιστές
  • μεγάλο κόστος εγκατάστασης τηλεπικοινωνιακών υποδομών διασύνδεσης και ακριβό υλικό τηλεφωνίας
  • μη εξοικείωση με τις τεχνολογίες τηλεφωνίας από το ευρύ κοινό προγραμματιστών
  • Οι τεχνολογίες web απαλλαγμένες από τα παραπάνω προβλήματα έγιναν το κύριο μέσο για τη διάδοση/διάχυση των πληροφοριών. Τα πράγματα άρχισαν να αλλάζουν με την είσοδο της προσέγγισης του ανοιχτού λογισμικού/λογισμικού ανοιχτού κώδικα στο χώρο της τηλεφωνίας (βλ. Asterisk) και του VoIP. Με τα εργαλεία αυτά υπήρχε πλέον η δυνατότητα να εγκαταστήσει και να φτιάξει εφαρμογές τηλεφωνίας οποιοσδήποτε με σχετικά μειωμένου κόστους εξοπλισμό και με υπηρεσίες που δίνονταν από τους τηλεπικοινωνιακούς παρόχους σε οικιακούς χρήστες.

    Το πρόβλημα όμως της ευρείας αποδοχής των εφαρμογών τηλεφωνίας παρέμενε μέχρι που μια νέα προσέγγιση υπόσχεται πλέον να δώσει λύση μέσω της σύγκλισης με τις τεχνολογίες ιστού και τη λογική της φιλοξενίας και την παροχή ως υπηρεσία (SaaS ή στη συγκεκριμένη περίπτωση VaaS: Voice as a Service): οι τηλεφωνικές υπηρεσίες βασισμένες στο σύννεφο (cloud telephony/voice).

    Θα λέγαμε ότι μέσα στο 2010, υπήρξε μια έκρηξη εμφάνισης πολλών εταιρειών και λύσεων προς την κατεύθυνση αυτή με τα ακόλουθα βασικά κοινά χαρακτηριστικά:

  • Παρέχεται ένα web based API μέσω του οποίου οι χρήστες/εφαρμογές μπορούν να καλέσουν βασικές υπηρεσίες τηλεφωνίας όπως η απάντηση κλήσεων, η αναπαραγωγή ήχου, η συλλογή επιλογών μέσω DTMF τόνων, η εγγραφή ήχου κλπ
  • Τα αποτελέσματα αποστέλλονται, στη συνέχεια, στα πλαίσια μιας αίτησης προς το διακομιστή της εφαρμογής για την περαιτέρω επεξεργασία και για να αποφασιστεί από την εφαρμογή πώς θα εξελιχθεί η αλληλεπίδραση
  • Η παραμετροποίηση/εγκατάσταση του απαιτούμενου υλικού, η εξασφάλιση τηλεφωνικού αριθμού/δρομολόγησης κλπ γίνεται από τον πάροχο χωρίς να πρέπει να ανησυχεί τον χρήστη
  • Έχει υιοθετηθεί πολιτική πληρωμής ανάλογα με τη χρήση με αποτέλεσμα το αρχικό κόστος εγκατάστασης να είναι πλέον μηδενικό
  • Κάποιες (με πρωτοπόρο τo tropo.com της Voxeo) προσπαθούν να εντάξουν από την αρχή και τις δυνατότητες αναγνώρισης και σύνθεσης ομιλίας
  • Τα χαρακτηριστικά αυτά έχουν αρχίσει να δίνουν μια νέα ώθηση στις τηλεφωνικές εφαρμογές και στον ολοένα και πιο πρωτοποριακό συμπληρωματικό συνδυασμό (και όχι βέβαια να λειτουργούν ανταγωνιστικά) με εφαρμογές web αλλά και εφαρμογές που αξιοποιούν άλλα κανάλια επικοινωνίας (πολύκαναλικές εφαρμογές) ώστε να μιλάμε πλέον για ανάκαμψή τους.

    Ανάμεσα στις πιο δημοφιλείς τέτοιες υπηρεσίες είναι:

  • Tropo (μέσω του Tropo WebAPI και ευρεία χρήση JSON)
  • Twilio (μέσω της υποστήριξης της TwiML)
  • Cloudvox|IfByPhone (με υιοθέτηση του FastAGI από τον κόσμο του Asterisk ως API
  • Teleku (UPDATE 2010-08-14 η οποία εξαγοράστηκε από τη Voxeo)
  • Invox
  • QuickFuse (με online γραφικό εργαλείο workflow)
  • VoiceSage
  • Παρόλο που με την προσέγγιση αυτή πράγματι διευρύνεται η βάση των προγραμματιστών που μπορούν να τις αξιοποιήσουν λόγω της απλούστευσης αλλά και η δυνατότητα για mashups, το βασικό θέμα είναι ότι το προγραμματιστικό μοντέλο επιστρέφει εκεί που βρισκόταν όχι πριν από τη VXML (και τον ενσωματωμένο form interpretation αλγόριθμο) αλλά ακόμη κι πριν από τους πίνακες καταστάσεων (state-tables ή state-machines).

    Αυτό που αναμένεται πλέον είναι, μαζί κι από την εμπειρία χρήσης της VXML σε δυναμικές εφαρμογές, τουλάχιστον όταν έρθει η ανάγκη για πιο πολύπλοκες εφαρμογές από αυτές ενός απλού κατευθυνόμενου διαλόγου ή μιας απλής business διαδικασίας, να αναδυθούν/προταθούν νέα μοντέλα και μηχανισμοί που θα δίνουν τη δυνατότητα στον προγραμματιστή ανεξάρτητα από την πλατφόρμα που θα επιλέξει να επιτύχει πιο εύκολα την επιθυμητή αίσθηση αλληλεπίδρασης (Voice User Interface).

    UPDATE: Μια πολύ ενδιαφέρουσα διάκριση σε γενιές συστημάτων IVR κάνει Nickolay Schmyrev, βασικός συντελεστής της ανάπτυξης του Sphinx στο άρθρο του εδώ.
    Ουσιαστικά αναφέρεται στις παραπάνω υπηρεσίες τηλεφωνίας ως τη δεύτερη γενιά μετά την πρώτη γενιά των εφαρμογών βασισμένων σε VXML και αφήνει υποσχέσεις για εφαρμογές τρίτης γενιάς βασισμένων στην υποβοήθηση της σημασιολογική ανάλυση του διαλόγου μέσα και από αξιοποίηση dialogue manager, όπως ο Ravenclaw, o DMCPP κ.α.

    Ανάγκη για «εμπλουτισμό» του data tag στο πρότυπο VoiceXML

    Καθώς το πρότυπο VoiceXML 3.0 είναι υπό διαμόρφωση και η μετάβαση από την έκδοση 2.1 έχει αρχίσει ήδη να υλοποιείται σε πολλές πλατφόρμες, είναι ευκαιρία να γίνουν κάποιες προτάσεις προς υιοθέτηση για τη διευκόλυνση των προγραμματιστών.

    Προσωπικά, πρόσφατα (για τις ανάγκες της «φωνητικής» εκδοχής της εφαρμογής e-Αποδείξεις) παρατήρησα ότι η -σωστή βάσει της έκδοσης 2.1 του προτύπου- συμπεριφορά της πλατφόρμας της Voxeo (αναφέρομαι στον voicebrowser πίσω από το evolution και όχι στο prophecy) κατά την αίτηση ενός data element ήταν η διακοπή λειτουργίας με ανακήρυξη σφάλματος. Κι αυτό γιατι η εφαρμογή επέστρεφε μόνο JSON απαντήσεις.
    Η μόνη λύση ήταν να υποστηριχθεί η επιστροφή απαντήσεων σε xml φορμά μέσω μιας προαιρετικής παραμέτρου (&format=xml) κατά την κλήση. Βέβαια, ιδανικά, όλες οι REST-based εφαρμογές, παρόλο που η τάση είναι σαφώς υπέρ του JSON, θα έπρεπε να υποστηρίζουν, τόσο από πλευράς υλοποίησης όσο και από πλευράς τεκμηρίωσης, και τους δύο τρόπους και να αφήνουν την επιλογή χρήσης στον εκάστοτε προγραμματιστή-χρήστη των αντίστοιχων web API.

    UPDATE 2010-09-04: Η παραπάνω επισήμανση είναι μέρος μιας (τη 5ης) από τις ..πολλές που πλέον έχουν αρχίσει να συγκεντρώνουν οι ενδιαφερόμενοι, όπως ο Dominique Boucher στο blog της Nu Echo. Ο αριθμός των drafts της έκδοσης 3.0 του προτύπου έχει φτάσει πλέον στο 31 και κάτι πάει να γίνει με την «υποστήριξη» JSON…

    Οι αξίες του Μηχανικού και η ανάπτυξη πληροφορι(α)κών συστημάτων

    engineering_value Πρόσφατα έπεσε στην αντίληψη μου μια ανάρτηση σχετικά με μια μελέτη με το παραπάνω θέμα, και μιας και ο συγγραφέας του προτείνει να ληφθεί υπόψη ακόμη και στην άλλη μεριά του Ατλαντικού, είπα να το αναφέρω και να το θέσω υπόψη των -πολλών- στη δική μας περίπτωση σχετικών φορέων.

    Το βρετανικό σύστημα και η …έφεση που έχει στις πιστοποιήσεις επαγγελματικών προσόντων (βλ) δεν φαίνεται να είναι και το καλύτερο πρότυπο για πολλούς από τους φορείς στο χώρο (βλ. π.χ. αντιδράσεις στην πρόσφατη διημερίδα για τις επαγγελματικές πιστοποιήσεις) ενώ οι διαφορετική φιλοσοφία του έχει τονιστεί και σε παλιότερες σχετικές ημερίδες.

    Η πρώτη θετική εντύπωση προκύπτει από τη συνεργασία του IET και του/της BCS για την έκδοση της συγκεκριμένης μελέτης. (Κάποιος που έχει εμπειρία από το σύστημα, θα μπορούσε να μας διαφωτίσει για τον εσωτερικό «ανταγωνισμό» για το ρόλο που παίζουν οι φορείς , δλδ τι κένα αφήνουν και πόσοι άλλοι φορείς προσπαθούν (ή εξαναγκάζονται εκ των πραγμάτων) να παίξουν το ρόλο τους ή να καλύψουν αυτά τα κενά; Θα απευθυνθώ σε κάποιους φίλους που έχω εκεί …)

    Σ’όλη τη μελέτη φαίνεται να τονίζεται η θετική συμβολή που έχει η υιοθέτηση της προσέγγισης μηχανικού (engineering approach) στην αντιμετώπιση των θεμάτων που έχουν να κάνουν με την ανάπτυξη πληροφορι(α)κών συστημάτων, που πλέον χρειάζεται να καλύπτουν απαιτήσεις μεγάλης κλίμακας αλλά και εγγυημένης απόκρισης, μιας και θεωρείται ότι ανήκουν στη λεγόμενη «κρίσιμη υποδομή». Από την άλλη καταγράφει ακόμη και τις «αντιδράσεις» πολλών επαγγελματιών του χώρου στο να χαρακτηριστούν «μηχανικοί» (engineers), επικαλούμενοι είτε κοινωνικούς λόγους, λόγους ιστορικής συσχέτισης του όρου με παραδοσιακές εφαρμογές (π.χ. πολιτικοί μηχανικοί) και άλλους πιο ..ουσιαστικούς λόγους.

    Τα πορίσματα αγγίζουν το θέμα του «επαγγελματισμού» (professionalism) σε όλα τα βήματα της προδιαγραφής, προμήθειας και ανάπτυξης τέτοιων συστημάτων, το ζήτημα της ένταξης σε ένα πλαίσιο κανόνων (εντάξει, με τις απαιτήσεις ευελιξίας που απαιτούν οι σημερινοί ρυθμοί, αλλά όχι και το απίστευτο σημερινό αλλαλούμ), της (ουσιαστικής) άδειας άσκησης επαγγέλματος, τη συνεχή ενημέρωση πάνω στα αντικείμενο (ως υποχρέωση τόσο του ενδιαφερόμενου όσο και του φορέα) κ.α.
    Επιπλέον, προτείνει να επιβληθεί η απαίτηση να εμπλέκονται σε όλα αυτά τα στάδια αποκλειστικά και μόνο «επιβεβαιωμένοι» (chartered) επαγγελματίες τόσο στην δημόσια διοίκηση όσο και στη βιομηχανία.

    Πιστεύω αξίζει -τουλάχιστον- μια ανάγνωση….Ελπίζω να βρω χρόνο να επανέλθω με άλλα αξιοσημείωτα αποσπάσματα από τη μελέτη…

    Παρουσία, Διαθεσιμότητα και Επικοινωνία Πραγματικού Χρόνου

    Τελικά οι συναντήσεις του OpenCofee έχουν πολλά θετικά…Πέρα από την ενημέρωση για νέες προσπάθειες μέσα από τις παρουσιάσεις και τις νέες γνωριμίες με άτομα και τάσεις είναι και ένα καλό κίνητρο για ραντεβού και συνάντηση στις δύσκολες συνθήκες «συνεύρεσης» (μην παρεξηγηθώ,ε;) της Αθήνας…

    Η τελευταία εκδήλωση ήταν μια καλή αφορμή να τα πούμε από κοντά με το Γιάννη (της K2Dynamics), φίλο και παλιό συμφοιτητή, και να ανταλλάξουμε απόψεις για τη …μάχη χαρακωμάτων (όχι δεν αναφέρομαι στα …μπάχαλα των ημερών) στο χώρο των υποδομών και των εφαρμογών με απαιτήσεις επικοινωνίας πραγματικού χρόνου (RAI – Realtime Application Infrastructure) ανάμεσα στα –σημειωτέον ανοικτά– πρότυπα SIP (και οι επεκτάσεις τύπου SIMPLE) και XMPP.
    O Γιάννης έχει ασχοληθεί πάρα πολύ με το θέμα ενώ στο XMPP στηρίζεται και η υπηρεσία ζωντανής υποστήριξης PresenceSpace που εδώ και λίγο καιρό έχουν λανσάρει. Ελπίζω να δοθεί η ευκαιρία να την παρουσιάσει σύντομα σε επόμενη συνάντηση του OpenCoffee μπας και ξεφύγει η θεματολογία των παρουσιάσεων από τον αμιγώς web 2.0 και social oriented χαρακτήρα που έχουν αυτή τη στιγμή.

    Βέβαια, η κουβέντα είναι μεγάλη μιας και είναι σε εξέλιξη ακόμη η προσπάθεια ενδυνάμωσης αυτών καθ’αυτών των πρωτοκόλλων (π.χ. θέματα ασφάλειας) αλλά και εύρεσης τρόπων για διαλειτουργικότητα (interoperability). Μάλιστα το συγκεκριμένο θέμα ήταν από τα βασικά στην τελευταία συνάντηση του IETF. Περισσότερα από τα …παρασκήνια εδώ και εδώ όπου ο Dan York (από τον κόσμο του SIP) συζητά με τον Peter St. Andre από τους πρωτεργάτες της XMPP (πρώην Jabber και νυν μέρος της Cisco) κοινότητας.

    Τελικά ξέκλεψα λίγο χρόνο για την Athens Digital Week…

    Όπως ήλπιζα βρήκα λίγο χρόνο για να παραβρεθώ στην Τεχνόπολη στο Γκάζι και στην πολυ-εμπειρία της Athens Digital Week. Η μόνη μέρα που μπορούσα (και ευτυχώς που δεν το ανέβαλα δλδ) ήταν η Πέμπτη, πρώτη μέρα του 4ημέρου που παρά τη – σχετικά με όσα μαθαίνω για τις επόμενες μέρες – μικρή συμμετοχή ήταν πολύ ενδιαφέρουσα…

    Ξεχώρισα κάποιες ομιλίες σχετικά με τις ελληνικές (και ακαδημαϊκές/εκπαιδευτικές) προσπάθειες και διερευνητικές κινήσεις στο χώρο του συμμετοχικού Διαδικτύου (web 2.0), τις …καλλιτεχνικές ανησυχίες στο χώρο του case modding, το κυνήγι των λεπτομερειών (μέτρηση ακόμη και για τις ..θορυβικές επιπτώσεις) των προσπαθειών ψύξης/overclocking αλλά και την πρωτόγνωρη για μένα συνεργασία της συμφωνικής ορχήστρας του Δήμου με πιο …ροκ όργανα για την απόδοση αγαπημένων μουσικών από ταινίες και videogames …

    Αρκετά τα εκθέματα και στο χώρο της ρομποτικής (πολύ καλή ένδειξη για τις δυνατότητες και τις προοπτικές περαιτέρω υιοθέτησης της «εκπαιδευτικής ρομποτικής») όπου έκλεψαν την παράσταση (κυριολεκτικά όμως, μιας και κοσμούσαν ακόμη και το εξώφυλλο του σημερινού Metropolis News) τα AIBO των «δικών μας» (εκ Πολυτεχνείου Κρήτης ορμώμενοι γαρ 🙂 ) Κουρητών.

    Καλή συνέχεια στην πρωτοβουλία αυτή…Αξίζει να ταξιδέψει και σε άλλες πόλεις ώστε την επόμενη φορά η συμμετοχή να είναι μεγαλύτερη. Εξάλλου, η συμμετοχή και η έκφραση μέσα από τις τεχνολογίες είναι αυτά που διακρίνουν τη συγκεκριμένη προσπάθεια από τις ..συμβατικές εκθέσεις τεχνολογίας και «προώθησης» των επιτευγμάτων της…

    Πότε βολεύει…ή παρακαλώ ενημερώστε με για τη διαθεσιμότητά σας

    Με αφορμή μια χτεσινή κουβέντα για μια ανάθεση διπλωματικής εργασίας είπα να αναζητήσω περισσότερα στοιχεία για τις λύσεις που προτείνονται αυτή τη στιγμή στο πρόβλημα του προσδιορισμού της καταλληλότερης χρονικής στιγμής για τη διεξαγωγή μιας εκδήλωσης γενικά (από επαγγελματικά meetings μέχρι κοινωνικές εξόδους, πάρτυ κλπ.). Ο βασικός στόχος είναι η τελική επιλογή να βολεύει όσο το δυνατόν περισσότερους από τους δυνητικούς συμμετέχοντες (αν όχι όλους) βάσει μιας «δημοκρατικής» προσέγγισης αντί της «συγκεντρωτικής» λύσης της μορφής «Έχουμε συνάντηση αύριο στις 3μ.μ. Φροντίστε όλοι να είστε παρόντες».

    Από τη δική μου εμπειρία (ακόμη και σε συναντήσεις με μικρό αριθμό ατόμων), την αρχική πρόταση (μέσω email) για συνάντηση την ακολουθεί καταιγισμός (εντάξει, δεν φτάνουμε και σε φαινόμενα χιονοστιβάδας) από άλλα μηνύματα για τη διαθεσιμότητα του καθένα, εναλλακτικές προτάσεις για το χρόνο διεξαγωγής κ.ο.κ. Η …οικονομία στα μηνύματα παρατηρείται συνήθως μετά τις συναντήσεις οπότε τα σχετικά συμπεράσματα (minutes κλπ) αργούν να …βρουν το δρόμο τους.

    Στο πλαίσιο, μάλιστα, των ολοένα και δημοφιλέστερων εικονικών συναντήσεων με συμμετέχοντες που μπορεί να προέρχονται από πολλά διαφορετικά μέρη (αλλά και time zones) το πρόβλημα δείχνει ακόμη πιο δύσκολο να λυθεί.

    Παρακάτω θα προσπαθήσω να βρω στοιχεία για τις διαθέσιμες αυτή τη στιγμή web 2.0 εφαρμογές που προσπαθούν να δώσουν λύση στο παραπάνω πρόβλημα, τις δυνατότητές τους αλλά και τα μειονεκτήματά τους (κατά πόσον απαιτούν «σύγχρονη» παρουσία των μελών οπότε και το πρόβλημα μεταφέρεται στο «πότε είστε διαθέσιμοι για να κανονίσουμε τη συνάντηση).

    Από τις πρωτοεμφανιζόμενες εφαρμογές στο χώρο φαίνεται να έχει χάσει όμως αυτή τη στιγμή τα πρωτεία λόγω κυρίως της στάστιμης σχεδίασης της αλληλεπίδρασης με το χρήστη. Στη βασική του λειτουργικότητα, κάποιος επισκέπτεται το site του Doodle, ορίζει κάποιες εναλλακτικές ημ/νίες και ώρες, δημιουργείται ένα URL, το οποίο αποστέλεται σε όλα τα ενδιαφερόμενα μέλη (πώς;), τα οποία μπορούν να επιλέξουν (ουσιαστικά ψηφίζουν, άρα η όλη διαδικασία μοιάζει με τη διαδικασία των ερωτηματολογίων (polls) ) εκείνες που τους βολεύουν. Τον χαρακτήρα της ψηφοφορίας τονίζει και το ίδιο το όνομα της επέκτασης της εφαρμογής για το Facebook: DoodlePolls.

    Η εφαρμογή αυτή έχει πιο απλή αλληλεπίδραση μιας και αντί της χειρωνακτικής εισαγωγής ωρών επιτρέπει το point & click πάνω σε μια οικεία μορφή ημερολογίου. Παρέχει επίσης μια γραφική αναπαράσταση των διαθέσεων των μελών (βάσει του ποια ώρα προτιμούν οι περισσότεροι) ενώ μπορεί να εισάγει κανείς διευθύνσεις από πολλαπλούς καταλόγους (π.χ. outlook, gmail κ.α.). Στα επιμέρους «καλούδια» η διασύνδεση με Google Maps κ.α.

    Στο άρθρο αυτό προτείνονται και εναλλακτικές εφαρμογές που επίσης άφησαν καλές εντυπώσεις.

    Η εφαρμογή TimeBridge φαίνεται να είναι η μόνη που προσπαθεί να ολοκληρωθεί με υπάρχουσες διαδικασίες προγραμματισμού εργασιών, όπως του Google Calendar και το Outlook Calendar.

    Με μια πρώτη ματιά, τα βασικά συστατικά στοιχεία για την επιτυχία μιας τέτοιας εφαρμογής φαίνεται να είναι:

    • web 2.0 χαρακτήρας, δλδ δυναμική (βασισμένη σε βάση δεδομένων), με χρήση AJAX (για δυναμικό front-end)
    • υποστήριξη πολλών «καναλιών» επιστροφής (π.χ. SMS, υποστήριξη πρόσβασης μέσω κινητού, γιατί όχι και μέσω τηλεφώνου – dtmf ή/και αναγνώρισης φυσικής ομιλίας)
    • η συνεργασία με υπάρχουσες λύσεις (προγραμματισμού εργασιών, καταλόγων επαφών κλπ) είτε online είτε «τοπικών»

    Για να δούμε αν και κατά πόσο μπορούν να καλύψουν οι παραπάνω αυτές εφαρμογές τις -μίνιμουμ καθημερινές απαιτήσεις- ή θα χρειαστεί να καταθέσει κανείς (ε, Δημήτρη; ) μια δική του πρόταση για τη λύση του προβλήματος …

    Cloud computing

    Το cloud computing είναι μια επέκταση της ιδέας του grid computing, όπου μεγάλες/πολλές υπολογιστικές και αποθηκευτικές μονάδες διάσπαρτες γεωγραφικά γίνονται διαθέσιμες στους χρήστες μέσω του Δικτύου με έναν ενιαίο τρόπο (βασισμένο στo δημοφιλές μοντέλο των web services) διαχείρισης και αξιοποίησης των πόρων αυτών, δίνοντας όμως ιδιαίτερη έμφαση στις δυνατότητες δυναμικής και ευέλικτης επέκτασης (ή/και συρρίκνωσης) της χρήσης των πόρων αυτών (scalability) ανάλογα με τις ανάγκες των εφαρμογών που τους χρησιμοποιούν.

    Αρκετές πλατφόρμες/υποδομές κινούνται πλέον προς την κατεύθυνση αυτή με δημοφιλέστερη αυτή τη στιγμή το Amazon EC2 ενώ τόσο η Sun όσο και η Google δείχνουν να έχουν μπει κι εκείνες δυναμικά στο χώρο (και το χορό).

    Μια πρώτη σύγκριση της Amazon EC2 με το -εν μέρει για την ώρα – ανταγωνιστικό Google AppEngine μπορεί κανείς να βρει στο σχετικό άρθρο του Παναγιώτη.

    Υβριδική προσέγγιση στην online αποθήκευση

    Η ιδέα της online αποθήκευσης στοιχείων συνεχίζει να ωριμάζει και να κερδίζει έδαφος χωρίς βέβαια να μπορεί ακόμη να εξαλείψει την ανάγκη για να έχουμε πρόσβαση στα έγγραφά και δεδομένα μας από παντού ακόμη κι όταν είμαστε «εκτός Δικτύου».

    Κάτι που ενισχύει την ..υβριδική προσέγγιση που φαίνεται να είναι τελικά και η πιο βολική υπό πραγματικές συνθήκες είναι η νέα δυνατότητα της υπηρεσίας GoogleDocs για συγχρονισμό των εγγράφων ώστε αλλαγές που έχουν συμβεί τοπικά και όση ώρα δεν έχουμε σύνδεση να μεταφέρονται στην online εκδοχή των εγγράφων και, αντίστροφα, αλλαγές που έχουν γίνει όσο βρισκόμαστε μακριά από τον προσωπικό μας υπολογιστή/φυλλομετρητή (ή ίσως μελλοντικά και όταν δεν έχουμε μαζί μας τη φορητή λύση αποθήκευσης) να υιοθετούνται στην offline εκδοχή αυτόματα με την σύνδεση στην υπηρεσία.

    Η δυνατότητα αυτή στηρίζεται στο Google Gears το λογισμικό που εγκαθίσταται ως επέκταση στον φυλλομετρητή και δίνει τη δυνατότητα πρόσβασης σε εφαρμογές Παγκόσμιου Ιστού ακόμη κι όταν δεν υπάρχει δικτυακή σύνδεση. Αυτό επιτυγχάνεται διατηρώντας μια εικόνα των δεδομένων τοπικά (cache). Για όσους ενδιαφέρονται να δουν πώς θα μπορούσαν να φτιάξουν μια εφαρμογή που μπορεί να λειτουργήσει ανεξάρτητα από το αν υπάρχει διαδικτυακή σύνδεση ή όχι, υπάρχει μια αρκετά επεξηγηματική περιγραφή λύσης εδώ.