On 1/26/07, Eric Hestenes <erichestenes at vikiwi.com> wrote: > The TOPAZ framework (see > http://www.plosone.org/home.action) has quite a bit of > appeal due to a substantial overlap in requirements and some very > interesting tools such as the ability to annotate XML documents. In spite of > this there have also been some concerns with the technical complexity of the > framework related to use of Mulgara and Fedora. There does not currently > appear to be a way to setup this data store as a high availability solution, > which is a project requirement. I have no idea about Topaz in particular, but I'd question why HA is a project requirement at this point in time. The costs far outweigh the benefits for a site that will inevitably be small at first. I can't suggest reading http://www.37signals.com/svn/archives2/dont_scale_99999_uptime_is_for_walmart.php strongly enough. "What you need is to embrace the goal of getting someone to care enough about your product that they'll actually complain when its down. Once the first complains starts to trickle in, you know you're riding something right, and then you start caring about adding another percentage point or two." > In the latter half of January the team has developed some prototypes using > Ruby on Rails for the purpose of testing out technical functions related to > tagging objects, searching, as well as threaded discussions. Several key > features we require are relatively simple to implement as a first cut using > Rails. For this reason we are proceeding to develop a functional prototype > with this technology. We are also actively prototyping the application HTML > using javascript and the DOJO library. There are a number of features that > we want to test out, and we expect the user interaction design to evolve as > a result of testing with a functional prototype. This is *wonderful* to hear. Prototype-driven design is the way to go. > Some additional technical decisions are documented here: > http://tools.dotank.nyls.edu/wiki/index.php/Peer_2_Patent/developer/use_cases_discussion/uc2_setup > > For those interested in the visual interaction design, we have links to a > site map as well as visual mockups here: > > http://www.communitypatent.org/project_docs/2006/10/site_map_exampl.html > > (warning the screen design PDF file is quite large) > http://www.communitypatent.org/project_docs/2006/11/screen_design_m.html Thanks for these links. Generally, I'm very, very impressed by the mockups- lots of information and yet minimal mess, and seem to be well focused on the most important bits. A handful of comments: * Love the use of sparklines in the screen design mockups. Generally, the front page looks great- chock full of useful information without being overwhelming. * what is the 'timeline' bar in p. 1 of the screen design pdf? Is that how far along in the process the given patent is? * the 'reviewers' yellow dot might benefit from the 'complexity' information that linkedin uses in their user dot- i.e., changing not just size but showing an increased number of lines which indicate increased 'intertwingliness' as the dot gets bigger. (Hard to explain; just look at a linkedin user list to see what I mean.) * I like Google's practice of adding a thumbnail of the first page of the patent on the overview page. I space looks precious on your proposed overview page, but that page seems to provide something tangible/distinguishing for the patent. * I might suggest calling 'tags' 'labels' instead (as google often does); tags are such a technorati term, and I sense this is reaching out to a broader audience. * What is the rationale for tagging individual pieces of prior art? That seems overkill, somehow, but I'm sure I'm just missing something obvious. * in the prior art submission pages, 'check all submitted prior art' should be a hyperlink to some method of checking, or at least to a description of how to check. > At this time mashups are not necessarily a > requirement but we'd like to consider this with a goal to have a more robust > technical design. If there are ideas for mashups that would be valuable, > please feel free share them on this mailing list. An obvious 'mashup' might be with Google's patent search and/or the PTO's own search; a greasemonkey script of some sort that displays very basic peer2patent information (the sparklines, maybe?) when browsing 3rd-party patent search engines would be great to have. Could be a very simple API- provide patent number, get back fragment of XML with links + sparklines images. > From a release standpoint, we are targeting to have functional builds of the > system for March 1 and April 1. Hopefully a first look will be possible > around March 1 timeframe. Good luck! Hope my small contributions are of some use. Luis
