2. About the presenters
William Jones, Research Associate Professor at the University of Washington
Manages the Keeping Found Things Found project
Lizhang Sun, MSIM (information management) program, 2nd year, graduating in
June.
Cody Stebbins, junior, Informatics program.
3. A manifesto: Take back our
information!
In better world, our information – content
and structure –
• has an integrated, unified existence
independent of any particular device or
application.
• Just as we use a diversity of tools for the
tending of a physical garden, we might
then apply a diversity of tools (“the right
tool for the right job”) as we tend our
growing gardens of information.
8. And we’re left to wonder: Why must
I choose?
“”I prefer zotero when I'm browsing
the net and searching for papers, but I
prefer a fully dedicated program like
mendeley for later editing and browsing
my own collection”. And, from another
user on the same discussion board: “I
don't want to be locked into using just
Mendeley or Zotero”
10. And what does export/import mean
now when our information is
everywhere on the Web?
11. Why can’t the applications come to
our information instead of vice
versa?
• “application” as in “the act of applying
or laying on”.
• We apply paint to a house; fertilizer to a
garden.
• Let the application be a thing we
apply to our information rather than a
thing we to which we “submit”.
13. But how?
• Wait for a new operating system to
unify everything? Cairo? WinFS?
• How quaint. Not in a Web-widened
world.
• Wait for a new standard?
• How long?....
• Move all our information to a “vault”
or a single store like Google Drive?
• These are just another application.
14. But how?
An approach that is stealthy, sneaky,
even … dare we say…subversive
(literally “to underturn, turn from
beneath”):
Take back our information even
as we leave it where it is.
15. Taking back our information in 4
steps.
Step 1. Leave the information where it is
(for now):
16. Taking back our information in 4
steps.
Step 1. Leave the information where it is (for now):
Step 2. Model the structure of this
information using itemMirror objects.
17. Taking back our information in 4
steps.
Step 1. Leave the information where it is (for now):
Step 2. Model the structure of this
information using itemMirror objects.
a. itemMIrror objects all support the same methods
on the front-end but, on the back-end, these
methods work with drivers specific to a given
“storing” application and its API.
b. These drivers provide read/write access to
information structures that are otherwise “siloed” in
the application
18. Taking back our information in 4
steps.
Step 1. Leave the information where it is (for now):
Step 2. Model the structure of this information using
itemMirror objects.
Step 3. Now other applications working
exclusively through these itemMirror
objects might provide complementary
ways of working with the information
structures:
19. Taking back our information in 4
steps.
Step 1. Leave the information where it is (for now):
Step 2. Model the structure of this information using
itemMirror objects.
Step 3. Now other applications working exclusively
through these itemMirror objects might provide
complementary ways of working with the information
structures.
Step 4. itemMirror objects persist their “mirrors” of
structure in synchronized XML fragments according to
an “itemMirror” schema.
22. A spring quarter project:
Build some HTML5 apps!
That all work “separately together” on the same
information
23. A spring quarter project:
Build some HTML5 apps!
That all work “separately together” on the same
information
- content _and_ structure -
24. A spring quarter project:
Build some HTML5 apps!
That all work “separately together” on the same
information
- content _and_ structure –
as accessed by different users
25. A spring quarter project:
Build some HTML5 apps!
That all work “separately together” on the same
information
- content _and_ structure –
as accessed by different users
from different platforms (Windows, Mac, iPhone,
Android, Windows Phone, …)
34. A plan for the remainder this afternoon
65 minutes, Student team presentations
= 5 teams *
(10 minute per presentation +
3 minutes commentary by judges afterwards).
5 minutes.
Judges make overall comments, confer and
vote on 1st and 2nd place.
(If deadlocked, Radek & William get to vote ).
10 minutes, “Our Space” demonstration
of team apps working together.
35. Optional: Some more background…
7.5 minutes, Lizhang,
Our XML schema & its two-way support for
extreme customizability through provision
for…
1. app-specific namespace elements
2. store-specific drivers.
7.5 minutes, Cody,
itemMirror object & special considerations,
overall, in the use of JavaScript for HTML5
programming.
36. Optional: Hands-on use & … Happy
Hour?
10 minutes or so…
Hands-on use of team HTML5 apps.
What do you think?
6pm (or so).
Happy hour (for survivors) at the
District Lounge (in Hotel Deca).
37. Scoring Guidelines (10 pts. possible)
3 points. Basic function and approach. Is
description of the “what?” (essential app functions)
and “who” (targeted users, competitors/similar
apps, collaborators & possible acquiring
companies) compelling?
5 points. The “how?” How compelling are
scenarios of use? What is good and not-so-good in
the user interface. How well does the presentation
describe the process of developing the application
and their use of underlying technologies (e.g., the
itemMirror object/drivers, JavaScript, etc.)
2 points. Quality of the presentation itself. How
clear? How effective at getting its points across?
(alternatively, how hard did you need to work to
understand?)
38. Also to consider…
Most students started the quarter
with little or no background in HTML5
or JavaScript.
The quarter is only 10 weeks long
and…
Code for even the basics in the
itemMirror object was not available until
week 4.
39. And consider…
The development environment is still
minimal (but rapidly improving).
In particular, students could not take
advantage of a shared UI framework
that includes basics such as…
a folder select dialog.
43. The itemMirror schema
43
• An XML schema that supports a
bundling of attributes used to
describe a “grouping item”
• (e.g. folder, tag, label, “album”, etc.).
• Based on the “noodle” structure:
nodes + outgoing links.
• Allows for modular, distributed,
simple representations of structure.
44. We need a unit of structure that is…
• Modular
• Work on the part (the unit) separate from
the whole.
• Small
• As small as possible. For speed
• Well-defined
• You and I should agree.
• Fully-expressive in aggregate
• Units combine to form the whole.
45. Grouping Item
grouping item is an information item
whose primary purpose is to form a
grouping of other information items
• (some of which themselves might be
grouping items).
• vary with the “storing” app: folders, tags,
labels, albums, headings, section tabs…
46. Fragment
• The metadata schema is modular – one
“fragment” of metadata per grouping item
• Each fragment represents a node and its
links (associations).
• Fragments collectively define a directed
graph (a multidigraph).
• Tools knit fragments together on-demand
(“lazily”) to create a coherent view (a
“document”)
47. Attributes
1. Common Attributes: pre-defined
attributes such as displayText
2. Namespace specific Attributes: App’s
own attributes
• iCal: dueDate, flickr: location
A. Fragment Level: Metadata describing the
node
B. Association Level: Metadata describing
the links
48. Bundles of common and Namespace-specific
attributes at both the fragment level
8/4/2013 48
49. And for each of a fragment’s associations
8/4/2013 49
50. Noteworthy details
• Only a few Common Attributes
Fragment
• schemaVersion, schemaLocation
• itemDescribed, displayName
• syncDriver, fragmentDriver, itemDriver
• GUIDGeneratedonLastWrite
Association
• ID, displayText, AssocaitedItem
• Allows Namespace Specific Elements
• Extensible Schema:
• Including optional “extras” commonly used
across apps(to provide more information and
for logging).
53. Responsibilities of the Drivers
• ItemDriver
• Responsible for
creating, reading, deleting, and updating
items.
• Example: DropboxItemDriver
• Create/read/delete/update folders and
files
• Accessed via AJAX calls to Dropbox REST
API
• Items stored on Dropbox servers
54. Responsibilities of the Drivers
• FragmentDriver
• Create, read, delete, update of XML
fragments
• Example: DropboxFragmentDriver
• Stores fragments in JS DOM
• Manipulate using DOM
• Persists fragments via AJAX and Dropbox
55. Responsibilities of the Drivers
• SyncDriver
• Updates fragments to reflect underlying
structure.
• Example: DropboxSyncDriver
• Removes associations for deleted items
• Creates associations for added items
56. Motivations behind Object Model
• Transitions between different storage
applications are seamless
• Avoiding “lock in” of data and logic
• Adapt to changes and scale
57. Motivations behind Object Model
• Transitions between different storage
applications are seamless
• Loading new drivers via HTTP
• Swapping drivers based on the drivers in
the Fragment
58. Motivations behind Object Model
• Avoiding “lock in” of data and logic
• For users: data isn’t siloed by an
application
• For organizations: avoid technology lock
in forcing costly rewrites, expensive
contracts
59. Motivations behind Object Model
• Adapt to changes and scale
• Storage medium, caching strategies, etc
are isolated to Drivers.
• Drivers change with demands of the
application, logic remains static.
• For organizations: avoid costly rewrites
to business logic for changing demand
• For developers: work at a higher level of
abstraction, separate problem into layers
60. Why JavaScript?
• JavaScript is the programming
language of client side HTML5 apps.
• Runs on a wide variety of platforms
• “Much easier to extend
JavaScript, than replace it” – Brandon
Eich, Designer of JavaScript, CTO Mozilla
61. Release information for ItemMirror
ItemMirror is quickly approaching
stability in public interface
If you are interested in working with
ItemMirror please contact
williamj@uw.edu, or talk to us after
64. Lessons learned
A shared framework and design
guidelines for user interface would
have been very useful.
And …??
65. By mirroring we might begin to
separate…
Surface
Structure & Content
Store (saving, synching, sharing)
PIM tools
mix &
match
Standard
formats
for
structure
& content
Pick &
choose
providers
66. A 3-way win
For developers
apps, written once, can work across a
range of storing apps such as Dropbox,
Google Drive, SkyDrive or even Facebook
and Flickr
67. A 3-way win
For developers
apps, written once, can work across a range of storing
apps such as Dropbox, Google Drive, SkyDrive or even
Facebook and Flickr
For storing app providers
itemMirror drivers to encourage
development to their platforms
68. A 3-way win
For developers
apps, written once, can work across a range of storing
apps such as Dropbox, Google Drive, SkyDrive or even
Facebook and Flickr
For storing app providers
itemMirror drivers to encourage development to their
platforms
For users
might freely switch between any number
of “itemMirror apps”, applied to the
same information
69. Tell your story in tenses future, present
& past
Uses different tools for each “telling”.
Future tense
What do you want to do? What will you do?
tools for brainstorming, planning, making reservations.
(Extended) present tense
What do you need to do now?
tools for time, task and to-do management.
Past tense
What happened? What did you do?
tools to organize photographs, create reports, post for
different audiences.
70. Next steps
More drivers
Google Drive, SkyDrive… Facebook?
Beyond the folder model
XMLFragments in a simple key / value database
Shared namespace elements for metadata standards
iCalendar – task management applications.
Dublin Core – for reference managers like Zotero &
Mendeley
“Phantom” summarizing fragments
Support for migration and multi-saves
71. A Vision
One structure.
A large directed graph.
Used in many ways.
Labeling and placing.
Navigation and search
As a basis for caching and backup.
Through many tools.
Non-disruptive innovation
71
http://feedback.mendeley.com/forums/4941-mendeley-feedback/suggestions/372255-zotero-2-way-sync; see also: http://forums.zotero.org/discussion/6174/mendeley/.
http://www.sciencedaily.com/releases/2009/07/090708132800.htmWhen the object was copmletion of a “document” via assembly line.
Could have been Google Drive, Skydrive, Sugar Sync, etc.
Nodes and links, disclaimers
In a future, we work on/in our houses of information using any number of tools. Our houses of information may be distributed across different stores through different services
The schema described is guided by a vision of “non-disruptive” innovation. Let tools continue to compete for our money, attention and time. But let this happen without forcing us to make a choice between the new tool and our current ways of working with and understanding our information and, in turn, help to realize the vision of information integration advocated by so many prior techniques, approaches and tools developed by the hypertext community