Blog

[Andreas Kollegger]

We've just this week started up a blog for the project, to which I'll
be posting developer notes and announcements. While continuing to
focus on getting the server delivered for next month, the blog will
provide a first-draft of documentation that will end up in the wiki.

Have a look here: http://blog.gatherdata.org

Cheers,
Andreas

[Jonathan Jackson]

Along these lines, andy has put up some potential logos. If anyone has
thoughts, please share.

[Yaw Anokwa]

i really like the basket logo. if the font could be made less googly,
it'd be even more awesome.

[Andreas Kollegger]

Hm.. I hadn't noticed that, but now that you mention it the 'G' has
very similar qualities, minus the serifs.

I'll try out some variations on that idea.

[Kieran Sharpey-Schafer]

Hi Andreas et Al.

REALLY like your logos - probably preferred the basket logo on first
impression - but the metaphor/symbolism that the honeycomb inspires
(bees gathering and collecting in a hive) is very clever and could
quickly get the idea across to people.

Also, from your original post, 'gather, transform, report' is a great
pay off line and I am completely sold! I especially like the little
diagram that illustrates this.

* Apologies for the delay in feed back, for some reason our firewall is
giving us a blank page for blog.gatherdata whilst www.gatherdata is
fine. I ended up using the browser on my phone to view the logos!

All the best,
Kieran

---

Kieran Sharpey - Schafer
Mobile Team Leader
www.cell-life.org

+27 021 469 1111

[Kieran Sharpey-Schafer]

Hi Andreas,

After having a peek at the gatherdata wiki, I saw the pilot use cases
section empty. I remember offering to help spec some rough outline
requirements previously, but I have no doubt you may already have some
documentation of your own.

For what its worth I just thought I'd share an export of documented
requirements (see pdf attached) for a project that followed a similar
theme last year. Obviously there is much too much detail on some of the
requirements (and the formatting of the export leaves a lot to be
desired), but some of the high-level structure you may find useful to
help define the scope (and what features people will ask for afterwards!).

I assembled the req from much of my experiences with various systems and
had extracted their common themes and features. So at the highest level
(as your diagram nicely shows) a generic system will have 3 major sections:

1. Data Input, 2. Data Management, 3. Data Output.

Taking these we can then 'drill-down' to highlight use cases of the system:

1.1 Manual Entry (e.g. web form)
1.2 Remote submission (e.g. web submission from mobile... perhaps cover
all mobile submission including bluetooth etc?)
1.3 Mass import (e.g. values from an old system that have been collected).

2.1 Entity / Attributes / Concepts Management
2.2 Forms Management
2.3 User Management
.... etc
(These are a little different to the document but you get the idea)

3.1 Data export (e.g. mass CSV dump of some collected forms/data)
3.2 Specific reports (e.g. fixed weekly report on stats of data collected)
3.3 Data analysis (e.g. something dynamic like OpenMRS's Cohort Builder)
3.4 Feedback to mobiles (e.g. delivery reports, submissison summaries,
patient sets)

In turn these can then be broken down again.

If there is any value in this do you think we should add some of it to
the wiki - in order to give some scope to what GATHER will be able to
do? I imagine that much of this is probably way beyond the scope of the
project and that the inital releases will try to cover one or two areas
in each section to begin with.

Let me know any thoughts you may have on this.

All the best,
Kieran

---

Kieran Sharpey - Schafer
Mobile Team Leader
www.cell-life.org

+27 021 469 1111