Thanks - all incredibly helpful and specific feedback. No good deed goes unpunished, you'll get a copy of some of the newest mockups this week. We are very much believers in iterative developer. We only know what works (and what doesn't) until we poke it and, more important, until real users poke it. That's why the emphasis is on making all the data transparent and accessible so that people can fix what they don't like, create better mash-ups and show what data is most useful. Please keep the feedback coming and we'll give you plenty to critique in the very next couple of weeks. We'll also want your input as we move forward on the kinds of tools and resources that will be helpful to non-lawyer technies and to non-legal code slingers to participate in this conversation. More to follow. Best, Beth On Jan 27, 2007, at 8:21 AM, Luis Villa wrote: > 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 > _______________________________________________ > p2patent-developer mailing list > p2patent-developer at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/p2patent-developer
