1. Bringing our
information
together
William Jones, Lizhang Sun, Cody Stebbins
The Information School,
University of Washington

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.

4. The continual export/import of
information is a cross we shouldn’t have
to bear.

5. Export/import is troublesome…

6. Export/import is “lossy”
Image from
http://chinesewhispersgame.blogspot.com/2010/06/s

7. Structures in particular are
distorted or left behind

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”

9. The export/import model is a
holdout from the days of desktop
monoliths.

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”.

12. But how?

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.

20. A spring quarter project:

21. A spring quarter project:
Build some HTML5 apps!

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, …)

26. Start with a folder structure in
Dropbox

27. Model structure in itemMirror
objects of JavaScript

28. Teams of MSIM students build
HTML5 apps working
exclusively with itemMirror
objects

29. Interactions are two-way
(write as well as read).

30. Objects persist their “mirrors” in
synchronized XML fragments

31. 1 2
3
4
Information “take back” in 4 steps!

32. Why HTML5?

33. Why HTML5? See:
 W3C, http://www.w3.org/2012/Talks/1120-owp-
plh/#(1)
 Cognifide, http://www.cognifide.com/blogs/ux/5
-reasons-why-html5-matters/
 develop, http://www.develop-
online.net/news/43964/Why-HTML5-makes-
strategic-sense
 “Why HTML5
rocks”, http://www.html5rocks.com/it/why
 Or search on “Why HTML5?”

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.

40. Team presentations
Let the judging
begin!

41. Demo (Lichen, Chia-Ching)

42. Our XML schema (Lizhang Sun)

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).

51. itemMirror (Cody Stebbins)

52. Object Model
ItemMirror
ItemDriver
Read/Write
for Items
FragmentDriver
Read/Write and
Manipulation for
Fragments
SyncDriver
Updates
Fragments to
Reflect
Underlying
Structure

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

63. William, Conclusions & Discussion

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

72. Our information…

73. Our information…
Together at last.

74. Next steps
(for you)
Try itemMirror wjones@uw.edu
Ask questions…
Thank you!