[bksvol-discuss] Re: Dashboard?
- From: "Andy B." <sonfire11@xxxxxxxxx>
- To: <bksvol-discuss@xxxxxxxxxxxxx>
- Date: Sat, 7 Aug 2010 19:34:33 -0400
In order to keep people and make things more systematic, you might have to
create something a little more than a list of things to just refer back to.
I do web development so if anybody needs recommendations, let me know.
-----Original Message-----
From: bksvol-discuss-bounce@xxxxxxxxxxxxx
[mailto:bksvol-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Scott Rains
Sent: Saturday, August 07, 2010 1:04 PM
To: bksvol-discuss@xxxxxxxxxxxxx
Subject: [bksvol-discuss] Re: Dashboard?
Andy,
Good suggestions. Hats off to you. I will reference this as we move forward.
Keep in mind that a very basic page is what we will release. The full
dashboard idea is a wish list item that may never materialize but I thought
might be useful to indicate the direction we want to go in order to make the
volunteer process as easy as possible.
Scott Rains
Benetech Fellow, Bookshare Volunteer Department
________________________________________
From: bksvol-discuss-bounce@xxxxxxxxxxxxx
[bksvol-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Andy B.
[sonfire11@xxxxxxxxx]
Sent: Saturday, August 07, 2010 6:27 AM
To: bksvol-discuss@xxxxxxxxxxxxx
Subject: [bksvol-discuss] Re: Dashboard?
The dashboard sounds pretty cool. I would:
1. Make sure that all steps required to be done in order are enforced in
that order. For example, if stage 1, 2 and 3 have to be done in that order,
refuse to let the person complete them out of order. 2. Create a few
multiple views of the dashboard. That way we aren't stuck to having it
displayed in whatever way engineering thinks is best. (templated is ok). 3.
Have a statistics section of the dashboard where it shows things like how
many books did the person scan, proof, how many have been send to
collection/rejected, how many pq books replaced this persons scanned/proofed
books and so on. 4. Each section of the dashboard could be modular. By this,
I mean that any steps/stages in the process someone isn't interested in
doing, they can hide/remove those stages/processes altogether until they are
interested in doing that process. Of course all core stages/processes are
required. An example of this is if someone wanted to do only proofing, then
they should be able to remove everything from their checklist/process list
except for 1. the core required processes for everyone and 2. the proofing
processes. This would require that borderlines are drawn between what a
scanner/proofer does (as well as any other work we can do), but from what I
can tell, it would be nice for some of us to have a clearly defined
position. I.E. if you scan a book, A, B, C and D are required of you. If you
proof, E, F and G are required of you. If D or A is mixed up in the scan
somehow, send it back to be redone. Of course, this doesn't apply for
someone who wants to proof/scan, but it does in a sense (we can't proof our
own scans).
-----Original Message-----
From: bksvol-discuss-bounce@xxxxxxxxxxxxx
[mailto:bksvol-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Scott Rains
Sent: Friday, August 06, 2010 4:22 PM
To: bksvol-discuss@xxxxxxxxxxxxx
Subject: [bksvol-discuss] Re: Dashboard?
Sure. Think of a control panel or anything that gathers in one place the
data and tools needed to accomplish a certain set of tasks that logically go
together.
In this case what we want to create is a sequential checklist of all the
steps that a volunteer should go through to improve the chances that a PQ
book doesn't bounce their submission.
The least sophisticated version would simply make the links clickable. These
would take the user to a separate page with the data needed at each step.
The next more sophisticated step would retain the list ordering but embed
each step's database as an element visible and searchable from within the
dashboard page.
A final step in sophistication would be to optimize this single-page
dashboard to reflect back to you where you were in the process, be
optimizable for all accessibility needs, collect results as exportable or
similar functions.
It is unlikely that the third level will ever be achieved. We are shooting
for something resembling the second level to correspond with publication of
the updated manual.
Side note:
You idea of a list of submission suggestions by genera, series, or other
category would be an excellent addition to such a dsahboard if the data were
collected into a spreadsheet and managed by a volunteer.
Scott Rains
Benetech Fellow, Bookshare Volunteer Department
________________________________________
From: bksvol-discuss-bounce@xxxxxxxxxxxxx
[bksvol-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Larry Lumpkin
[llumpkin@xxxxxxxxxxxxx]
Sent: Friday, August 06, 2010 1:01 PM
To: bksvol-discuss@xxxxxxxxxxxxx
Subject: [bksvol-discuss] Dashboard?
Scott, can you explain what a dashboard is and now to use it? I'm not
familiar with this concept.
To unsubscribe from this list send a blank Email to
bksvol-discuss-request@xxxxxxxxxxxxx
put the word 'unsubscribe' by itself in the subject line. To get a list of
available commands, put the word 'help' by itself in the subject line.
To unsubscribe from this list send a blank Email to
bksvol-discuss-request@xxxxxxxxxxxxx
put the word 'unsubscribe' by itself in the subject line. To get a list of
available commands, put the word 'help' by itself in the subject line.
To unsubscribe from this list send a blank Email to
bksvol-discuss-request@xxxxxxxxxxxxx
put the word 'unsubscribe' by itself in the subject line. To get a list of
available commands, put the word 'help' by itself in the subject line.
To unsubscribe from this list send a blank Email to
bksvol-discuss-request@xxxxxxxxxxxxx
put the word 'unsubscribe' by itself in the subject line. To get a list of
available commands, put the word 'help' by itself in the subject line.
Other related posts:
