I still like the concept of a Task. When I heard that word I automatically thought of the description that Martin provided: That of a user setting out to accomplish a specific and narrow goal in OpenJUMP. (Example: Merge two (2) data sets.)
I almost wonder if the concept of a project really needs to be incarnated in software. To me a project is more of an entity I manage on the file system. (Example: I store the data sources and metadata for each "project" in a separate part of the file system.) Still, a separate software utility that managed individual JUMP "tasks" is intriguing. I'll have to chew on this some more. I would personally be in favor of restoring the use of the word "task" in OpenJUMP, instead of project. I also find the idea of an "organizational layer" or component above a project interesting. (Martin used the example of a data source that can be shared among projects.) It seems having a data source catalog for OpenJUMP to manage these "common" data sets would be a step in this direction. The Sunburned Surveyor The Sunburned Surveyor P.S. - Thanks to Martin for this explanation. On 8/28/07, Martin Davis <[EMAIL PROTECTED]> wrote: > Yes, good point. That is closer to the technical level, which avoids > any confusion from connotations of the word "Project". > > Any ideas for what you'd call the existing Task window (now branded as > Project in OJ) ? I guess View or Map is an obvious possibility. > > Paul Austin wrote: > > Another common metaphor used is the workspace concept. > > > > Paul > > > > Martin Davis wrote: > > > >> Finally getting around to answering this... > >> > >> I'll start out by saying that the idea of Projects and Tasks was never > >> really fully realized or tested out in the real world. It was primarily > >> motivated by the observation that there was really room for higher > >> levels of organization than just the individual view windows (which is > >> the only visible level that JUMP provides). > >> > >> The concept was that a user would be working a project, which would > >> encompass one or more tasks. Each task would likely take place in a > >> separate view window. The project is an organizational concept which is > >> used to manage various resources, which should all be available to the > >> various tasks. Resources would primarily be data sources (files, DB > >> connections, images, etc) - but which could be anything else which would > >> be loaded for just that project. (This could be custom styles, > >> functions, etc. I'm guessing that if this facility was available it > >> would quickly become obvious which things should be associated with a > >> Project) > >> > >> The ultimate goal was to have an actual view frame which showed the > >> project and the associated resources. This would be sort of like the > >> Catalog in Arc. Data sources could be dragged to Task windows. The > >> lifetime of the FeatureCollections underlying Layers could be > >> Task-scoped or Project-scoped. > >> > >> There's probably a level above Project, too. Often a data source will > >> be used in multiple Projects. Maybe it would be possible to drag'n'drop > >> Project resources between different Projects in two JUMP instances. Or > >> maybe a single JUMP instance should support having several Projects open > >> - but that could get confusing. > >> > >> I suspect that at the moment people use Project = JUMP Instance (I know > >> I do). But I notice that in OJ Project has been "demoted" to being > >> one-to-one with a view window. I think this is limiting - why shouldn't > >> a project have more than one view window? And if that's the case, the > >> concept of the view windows needs a name - hence, "Task"! > >> > >> The real problem is the confusion caused by the fact that the original > >> "Open/Save Project" menu functions actually saved a single Task. This > >> was because we didn't have a visible "Project container" which we could > >> save instead. But IMO it would be a good thing to head towards that > >> more general model, and not do anything to prevent getting there. > >> > >> HTH - Martin > >> > >> Larry Becker wrote: > >> > >> > >>> To pique Martin's interest, I'll just say that I like the original > >>> JUMP "Task" terminology. The problem with "Project", IMO is that the > >>> word is confused with the idea of "projections", at least in English. > >>> Lots of other other software uses the term "Project" too, which can be > >>> both good and bad (bad to me). I had never heard of an application > >>> using the term "Task" to describe a collection of objects, but I > >>> thought it was immediately intuitive to anyone who heard it. > >>> > >>> regards, > >>> Larry Becker > >>> > >>> /8/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>>> Martin, > >>>> > >>>> In a message from May you wrote: "(BTW, sSometime I should write up > >>>> our original idea for the model of Projects and Tasks - I think > >>>> there's some confusion about why we chose the terminology we did.)" > >>>> > >>>> Is there any chance you would have a couple of minutes to provide a > >>>> brief explanation of the distinction between a task and a project? > >>>> > >>>> The Sunburned Surveyor > >>>> > >>>> ------------------------------------------------------------------------- > >>>> This SF.net email is sponsored by: Splunk Inc. > >>>> Still grepping through log files to find problems? Stop. > >>>> Now Search log events and configuration files using AJAX and a browser. > >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >>>> _______________________________________________ > >>>> Jump-pilot-devel mailing list > >>>> Jump-pilot-devel@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
