Hi David,
I think this is a rather interesting approach.  Personally I think this
is a good direction for Exhibit to move in.  There's no one particular
item you mention that I think is more exciting then the other.  Actually
that's not true, the way you're presenting the database like structure
of the JSON files is fairly keen, provided that for people wanting to
use Google spreadsheets or some other service can attach it through the
<script> tag and not using the onLoad call.  I also think that breaking
the various facets up into movable parts is for the better.  The Fixed
Collection view seems interesting, could be more powerful too if it can
be exported to Feedburner or RSS, that way when one updates the site and
a new "latest paper" gets added people who have the sites RSS feed will
know of the change.  As for some of the "ex:" values, the facetStyle for
example; it would be interesting if we could see something like:
ex:facetStyle="timeline, tile, detail" or remove one or two.  and then
which ever ones are listed display with the option to change the view
style.  That seems also like what the ex:viewClass does, perhaps a merge
of those to elements.  Although I wouldn't rely to heavily on my input
as a Javascript programmer, I'm more of a php, ruby, html, css guy. 
It's very interesting though, keeps me awake all night trying to think
of things to make into exhibits... and then looking at all that code. 
No wonder I'm single ;)
Cheers,
Derek

Derek Kinsman
The Idea Company

New Media Designer

http://www.ideacompany.ca/
http://boring.ambitiouslemon.com/
1.416.371.5652



David Huynh wrote:
> Rereading this email, I'm hearing "more flexibility" :-) Which is not 
> surprising to me.
>
> Exhibit is a different beast than Timeline, and I was in design hell 
> when I started writing Exhibit even after having written Timeline a few 
> months before. Timeline is quite self-contained: it's a rectangular box 
> that you drop wherever you want into your page and that's almost the end 
> of the story. Exhibit, on the other hand, has many parts and, thus, does 
> not happily want to be wrapped as a single widget, especially as a 
> faceted browsing widget. So perhaps we should break it into smaller pieces.
>
> -----
> The first piece to break of is the database. But there's more to just 
> breaking off the database. We web developers have enjoyed the presence 
> of the global variable "document" that lets us manipulate the document 
> object model and create dynamic web pages. I'm hoping that we can 
> introduce another global variable called "database". It will get 
> automatically populated with data linked from the web page and it lets 
> us manipulate that data through a database-like interface. For example, 
> you can write something like this:
>
>   <head>
>     <script type="text/javascript" src=".../exhibit-api.js"></script>
>
>     <link rel="data" type="rdf/json" href="my-recipes.json" />
>     <script>
>       function initialize() {
>         var recipes = database.getSubjects("type", "Recipe");
>         for (var recipe in recipes) {
>           ...
>         }
>
>         var database2 = database.createDatabase();
>         database2.loadData("my-friends.json");
>         ...
>       }
>     </script>
>     <body onload="initialize();">
>       ...
>     </body>
>   </head>
>
> Initially, you would need to include exhibit-api.js to get "database". 
> But after a while, perhaps your browser will come built-in with a native 
> implementation of "database". Now if "database" is built in, then it can 
> load data from other domains, too, and we won't need the JSONP hack. 
> Some interplay between the "database" on each web page and Piggy Bank is 
> possible.
>
> -----
> Once the database is broken off, it's more natural to break the UI off 
> into small pieces. It'd be nice to write small blobs of html code as 
> follows and place them _anywhere_ on the page:
>
>   <!-- define a collection of items -->
>   <div ex:role="collection"
>     ex:query="select ?x from ?x type Recipe"
>     id="recipes-collection"></div>
>
>   <!-- create a view and bind it to the collection above -->
>   <div ex:role="view"
>     ex:collection="recipes-collection"
>     ex:viewClass="Exhibit.TileView"></div>
>
>   <!-- create another view that will be displayed in parallel with the 
> first view -->
>   <div ex:role="view"
>     ex:collection="recipes-collection"
>     ex:viewClass="Exhibit.TimelineView"></div>
>
>   <!-- create a facet, maybe put this on the left side of the page -->
>   <div ex:role="facet"
>     ex:collection="recipes-collection"
>     ex:label="family"
>     ex:projection=".author.familyName"></div>
>
>   <!-- create another facet, maybe put it on the right side of the page -->
>   <div ex:role="facet"
>     ex:collection="recipes-collection"
>     ex:label="decade"
>     ex:projection="dateRound(.date, 'decade')"
>     ex:facetStyle="timeline"></div>
>
>   <!-- maybe we create another collection -->
>   <div ex:role="collection"
>     ex:query="select ?x from ?x type Chef"
>     id="chefs-collection"></div>
>
> The ex:collection attributes bind views and facets to collections and 
> make sure everything updates itself in sync with the other parts. There 
> is a lot of freedom to arrange bits and pieces of the UI to suit your 
> need: sprinkle some facets on the left, some on the right, put 2 views 
> in the middle--a timeline and a tabular view, add a fixed collection at 
> the top that never gets filtered (e.g., "My 5 latest papers"), ...
>
> Thoughts?
>
> David
>
> _______________________________________________
> General mailing list
> [email protected]
> http://simile.mit.edu/mailman/listinfo/general
>
>   
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general

Reply via email to