search

LaxmidharMishra / agrovoc-cs-workbench

Automatically exported from code.google.com/p/agrovoc-cs-workbench
0 stars 0 forks source link

GUI improvement - specify "demo" where appropriate #451

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

To avoid confusion it would be good if the interface to the demo version 
reported "demo" in the title

What version of the product are you using? On what operating system?

http://202.73.13.50:55123/agrovocv10demo/

Please provide any additional information below.

Original issue reported on code.google.com by caterina...@gmail.com on 13 Oct 2010 at 12:17

GoogleCodeExporter commented 9 years ago 
That's a bit of a pain because it means modifying the resource bundle after any 
deployment. I think having it in the URL should be enough.

Original comment by yjaq...@gmail.com on 26 Nov 2010 at 1:15

GoogleCodeExporter commented 9 years ago 
Please, let me insist on this point. After my comment to this specific issue, I 
try to explain you why I consider such a point very important. Please be 
patient and read through. 

----

Please correct me if I am wrong:

The "demo version" differs form the "development version" only in the data set 
it uses, so that editing done through the demo version does not affect the 
"master" repository. 

Then we can simply start emphasize the bit in the GUI showing the data set 
used. Cf screenshot attached, where you can read:

"caterina signed in as (Administrator) to: Agrovoc for demo"

It could say instead: ".... AGROVOC DEMO" in bold or something like that. 

In practice, this means changing the label used to show the data set, not the 
software itself. 

----

Now, let me explain you why I insist on this point. 

It turned out two editors entered data in the demo version instead of the real 
one, not realizing where they were. In one case, some 1000+ terms were entered, 
in the other one some 200 or 300. In the first case it is impossible to have 
the terms entered in the proper place in a reasonable time because the editor 
is now somewhere in the wood doing field work, and will be back to Iquitos only 
sometime early next year. So, we wait until she is back to re-do the work. But 
obviously after such a long time any re-doing work will simply loose 
priority... So, a likely scenario is that either we loose that data, or we move 
it sort-of-automatically, which is complicated by some mistakes she made while 
logging into the WB (confusion with accounts and roles) and editing the data 
(confusion due to missing written guidelines to be used as reference). 
Moreover, even if this specific case had a happy end, we must learn from it and 
by all means avoid that similar confusions take place in the future. 

btw, This is also the reason why I proposed to avoid using a "development 
version" to let editors work. Remember they are mostly librarians or 
biologistis and the like, using pc in a completely different way from IT 
people. So for "average" editors, working on a version that is claimed to be 
"under development" may be quite confusing. And in a situation of confusion you 
cannot foretell what people will do! 

Finally, if the idea behind making editors use the devleopment version is to 
have them contribute to functionality testing... well, I begin to believe this 
will never happen. Interacting with a formal issue tracker is sort of 
intimidating to non-IT guys and implies a steep learning curve...

Original comment by caterina...@gmail.com on 26 Nov 2010 at 3:35

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by yjaq...@gmail.com on 10 Mar 2011 at 11:47

GoogleCodeExporter commented 9 years ago

Original comment by yjaq...@gmail.com on 10 Mar 2011 at 11:47

GoogleCodeExporter commented 9 years ago

Original comment by yjaq...@gmail.com on 10 Mar 2011 at 11:51

GoogleCodeExporter commented 9 years ago

Original comment by yjaq...@gmail.com on 10 Mar 2011 at 12:03