Open jsilvestre opened 12 years ago
This is great, i've nothing else to add :D
Since we've been discussing the marker's data inside the marker type for pets, trainers, crafting items, ... I have added a new concept in the crowdsourcing tool.
The concept of "sets of fields" or fieldsets, depending on what is good english (:D) works as following:
I chose to do things that way because it makes fieldset reusable (so edition, like changing the key "wikiLink to "link_wiki" or whatever is superfast).
Currently the UI is really messy (and I'm polite here !) and I already have ideas to make it usable. What you will see is the functional version of that concept so we can say "okay, we like it" or "this clearly sucks, let's find something else". I'm pretty sure that with a good UI (again, will working on it after BWE3) this system will be fine.
Does this affect GW2C's code/config (i have some trouble understanding what you're saying ^^ )
Nope this is just a new scenario (yeah I didn't take time to format it like the other scenarios ^^) for the backend ! :)
Hey,
This is a first draft of how I see the application. I also add a [important] on special features we need to have for the next beta week-end. I will use a special branch to develop a quick-and-not-too-dirty version of the app by july 22th.
Since this is a draft, do not hesitate to give ideas, add scenarios, remove scenarios, modify scenarios. Maybe we talk about the general structure of the site here and open one for each scenario so we can talk in details of what we want to avoid confusion. When we have what we want I will create tasks on Trello.
Scenario 1: Homepage
When a random use lands on the homepage he can browse the modification history. There are two parts in this history : the last ten (arbitrary number) merged modification and the next 10 in the pending queue. When the user clicks on a link, he can view the "diff" version of the map administrators had when we merged it or the "diff" administrators will see. They can report an error on already merged modifications (see scenario 3 and 5) with a comment.
Scenario 2: Login [important]
Administrators have the ability to log-in into the restricted area.
Scenario 3: Restricted area: homepage
The admin homepage allows administrators to browse all the past and the pending modifications. They can specifiy criterias to see specific pending modifications (ie: "I want the pending modifications that are related to a heart marker").
They also have a list of all error reports from the user. We must discuss how we handle it, see scenario 5 for ideas.
[important] We need a pending modification list in a FIFO style for BWE3.
Scenario 4: Restricted area: merging tool [important]
This scenario applies to "not merged yet" modifications.
This is the core of the application. A modified version of GW2C that allows the administrator to preview the changes. The administrator can marker as accepted or rejected each modification individually and then merge the accepted ones. When a merge action begins, the system checks if a another modification has been merged in the time of the validation process to avoid conflicts during an eventual concurrent usage by two administrators.
Scenario 5: Restricted area: modification rollback/edition
This scenario applies to "already merged" modifications.
An administrator can rollback a change (not only the whole modification, but a single change in a modification). Also, he can modify texts and offsets of markers.
Not really more to say since this would require more work of how we want to manage errors.
Scenario 6: Restricted area : options' page
The options page has 3 sections.
The general option section allows administrators to modify generation options like the resources path, if we want to minimize the output file, how we deploy the output file, etc..
The areas configuration section allows administrators to define the name, the range level and the ne and sw lat/lng of an area.
The asset section allows administrator to manage markers' groups and markers (id, label and icon filename).