Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GW2C-Backend: organization and features #5

Open
jsilvestre opened this issue Jul 1, 2012 · 4 comments
Open

GW2C-Backend: organization and features #5

jsilvestre opened this issue Jul 1, 2012 · 4 comments

Comments

@jsilvestre
Copy link
Collaborator

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).

@lpdumas
Copy link
Owner

lpdumas commented Jul 1, 2012

This is great, i've nothing else to add :D

@jsilvestre
Copy link
Collaborator Author

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:

  • we define set of fields that are composed of fields. Each field is actually a "key" (name, desc, link_wiki, whatever we want and need in GW2C).
  • we define the marker groups and their marker types.
  • we link each marker group and each marker type to a fieldset.
  • we can give values for each fields of the fieldset for marker group/marker type.
  • obviously each value you set has a translation in all the languages we need (supported languages are defined in the options).

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.

@lpdumas
Copy link
Owner

lpdumas commented Jul 17, 2012

Does this affect GW2C's code/config (i have some trouble understanding what you're saying ^^ )

@jsilvestre
Copy link
Collaborator Author

Nope this is just a new scenario (yeah I didn't take time to format it like the other scenarios ^^) for the backend ! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants