wiki:Protocols

Version 4 (modified by fknauft, 14 years ago) (diff)

--

Meetings

20. Jan. 2010

27. Jan. 2010

3. Febr. 2010

  • Modules-Map (Falk)
  • Workspace Layout by Christopher
  • ChinaGIS Developer Wiki: Goals, Rules & Vocabulary
  • Discussed Issues:
    • Elements of the user interface and functioning: question, whether functions should be splitted up/ combined/ or grouped more practically.
    • The Modules-Map should be modified in a way, that a programs skeleton clearly differentiates between functions and workflow/ on-screen options. Functions then can be grouped hierarchically, subsequently the grouping/ splitting up of options should be defined. (The map should make clear which functions are already implemented.)
    • Questions concerning the user interface:
      • Should options, like search function etc., included into each block, or in a general menu?
      • How to deal with conflicting situations in contemporaneaous opened blocks (editing, modifying, deleting in different blocks at the same time)?
      • dynamic user interface, which allows to create a front page according to the users preferences, displaying the most commonly used options (should there be an extra management window?)
    • During table creation, the programm should already signalize the user, whether a table already fulfills the conditions for mapping (containing choords or gis_ID) or not visually (f.e. changing background color, icons).
    • The programm should contain a "Virtual Playground" to shorten the process of creating maps from scratch, if allows the manipulation of data in a view and displays the modifications visually immediately on map.
    • A question is how to handle table combination conveniant (f.e. if choosing from not only two or three, but many tables).
    • Another remaining question is, how the programm should deal with views, which combine data from different tables in a way that doesn't make sense (although they are presentable on map, because a gis_ID or choords are given).
    • postponed question: use of eSciDoc

10. Febr. 2010

  • Discussed Issues:
    • Handling
      • Seperation into two different modes,
        • 1st mode: for the purpose of "playing around", testing features and getting an overview; this mode contains also advices, which will teach the user how to create and modify tables
        • 2nd mode: workspace, in which projects can be created, modified, and finally published
      • Account management should be seperated from the workspace area.
      • Search functions will be implemented into blocks, so it will simplify the handling and makes it unnecessary to switch between frames or windows.
      • The option of saving the users configurations should be saved on the server.
    • Views and tables
      • Views are supposed to allow "playing around" by quick modifications and combinations of data from other tables, but since they are created as sessions in the browser only, but nothing is written on the server, this holds the risk of data loss.
      • Should there be an option to save views to the server too? Should the log out option fulfill this function (there's a risk that many users will just close the browser instead of logging out first), or should there be a periodical auto save (which will cause much traffic with many users)?
      • How to create the option to save modified views as a permanent project, which doesn't get deleted with the end of the session?
    • Combination of tables
      • Should there be parameters that qualify valid tables, e.g. at least one mappable date?
      • Which factors should be combined in what way to allow the combination of tables?
      • How will authorship be handled in combined tables? Will the origin of data be copied automatically into the metadata of one's own created table?
      • When using other tables into one's own tables, save the data (makes the tables bigger and excludes the option of updates, if this is desired) or just the source (holds the risk, that the original table gets changed, which influences the own table in case that this is not desired)?
      • If there is an option to choose the same tables from different dates (versioning), it will have to be made clear for the user.
      • When only using referrence to other tables, how to allow change parts of these tables (f.e. having a location, to which I contradict and therefore want to change this in my table)?
    • GUI
      • often used tables should be added to the workspace for easier access
      • an option most recently used tables
      • allowing modifications to be saved permanent (see above) - automatically? when using the log out button?
      • different colors for different blocks, to make the handling more intuitionally, f.e. different colors for tables and views (how to deal with modified views?)

17. Febr. 2010

  • Discussed the CHGIS-GUI Prototype
    • Handling of Workspaces has to be made clear for the users:
      • primary use for cooperative projects
      • possible customization according to user demands
      • "Home" menu includes in contrast account management and is aimed at individual working
      • The Workflows definition suggests workspace "as a set of user-created tables and "bookmarked" foreign tables/views, all belonging to the same project". A question yet to decide is, whether there should be multiple workspaces for different projects, or if one workspace will contain all participated projects as subpoints. This issue depends on the definition of "project".
      • Different workspaces/ blocks should have different colors to make the handling more intuitive.
    • Issue of getting into contact with the creator/ owner of a table
      • Tabels must be generally open to browse, or else the search function makes little sense.
      • In case that an information is required or permission for the usage of a tables information is desired, should the meta data of a table include email contact information of the creator, or should the contact be handled by an inbuild message system?
      • While it makes sense to "attach" messages and notifications to the related workspace, there should be an option to read all messages together at a single place to make the handling easier.
      • How to handle abandoned tables (tables, that someone has a right on, but doesn't continue anymore to work on)?
    • Mapping
      • mapping styles should be changed and simplified to only allow possible display options
      • adding the options of layers, which can be chosen seperately, to the map
      • An additional interface was suggested, in which views from different tables can be combined to a map of multiple layers.