FEATURES AND ENHANCEMENTS FOR OPENXDATA MOBILE CLIENT

[Donald mteka]

Hi all,
 Glad to see you back after long holiday break.
 We have done extensive exploration on mobile client and server module on server side and come up with some features/enhancements and fixes on the mobile client. We hope this could be of interest to the general Openxdata community and we bring them here to share.
 We hinted this out in on of the previous iteration meetings, since then we have been in touch with Brent and Jorn and we promised to bring this soon to the devs.
The source code will be made available for review when we a given a  commit account (in test environment?), also the package application can be uploaded to the dedicated url for testing people to download directly.

The attachments gives some light on what has been done, and could open room for more features. We hope to work more closely on fixing defects and bringing more features to the mobile client. 

Best regards,
--
Donald Mteka
+255653105004

[Sarah Bird]

Hi Donald,

It's great to see you getting engaged with openXdata - welcome.

I'm not sure entirely how Brent and Jorn have suggested you contribute, but I would certainly think that many of the features you have worked on could be made into tickets and the code added to trunk in patches incrementally with core developers reviewing your patches.

I am not a developer, so I will just comment on the features you have listed:

1) Save Partial Forms - great - this is something I think that a number of users would be interested in seeing
2) Edit display template - I'm not sure what you mean by this - maybe some screenshots will help - I have reviewed your presentation also but wasn't sure what you were referring too.
3) Display template for repeat data - again not sure what you are referring to here
4) Repeat data are displayed as RepeatQuestion[Count] - great - I think that will be a nice addition
5) Selective upload of data - this is functional in current version of mobile client
6) Multi-level of uploading data - this is mostly functional in current version of mobile client - you can do studies and individual single data - adding upload for a whole form could be a good addition. I do not think, personally, there is much added value in uploading per study and it would create menu clutter
7) Retrieving data for given search keywords and creation date - this would be a very useful feature - I am interested to see how you've implemented it
8) Full retrieval of data for editing - this is functional in current version of mobile client
9) Deep repeat questions - you mean repeat questions within repeat questions?
10) Grouped display of uploaded data - An upload log has been implemented in latest mobile client - what functionality do you have in addition to this?
11) Improved URL settings & Impossible to login - there has been a major overhaul of upload/download settings and how authentication works to the server when url is changed or login is wrong etc - you should check it out - a lot of it is behind the scenes so i'm not in the best place to comment.

I hope to see you starting to add tickets to cover your new features soon so I can start commenting formally and testing out your work.

Sincerely,

Sarah Bird

--
You received this message because you are subscribed to the Google Groups "openXdata Developers" group.
To post to this group, send email to openxd...@googlegroups.com.
To unsubscribe from this group, send email to openxdata-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openxdata-dev?hl=en.

[Jørn Ivar Klungsøyr]

Hi Donald,

 

Thank you for taking the time to prepare more information about the work you have done on improving openXdata functionalities.

And we look forward to close collaboration as we move forward.

 

Without going into each of the functionalities you have described, I clearly see that you have a lot of improvements that are of value and that we should work on incorporating into openXdata. In earlier days we would have allowed these kind of contributions to be fairly directly merged in, but through the improvements of the community processes this last year, we want to ensure that we fold in contributions piece by piece according to community concensus and priorities and linked to individual tickets for each piece (that is a patch). This way features can be included, but we ensure transparency and documentation of what goes into each iteration and subsequent release.

 

What I hope we can do from here is to bring your group into the regular development process and iterations and through that fold in features and enhancements that the community agrees on to bring in.

 

I’ll get back separately on an experimental branch where you can upload the changes – though as mentioned this would not mean that all those changes are merged directly into trunk.

 

The next step from here would be that each of the changes and new functions you have done are made into tickets on trac and then for each of them a patch is created. Each of the tickets can then be prioritized in the backlogs – some of them may need additional discussions and adjustments based on concensus. Each patch will then be reviewed by another developer before it can be included. For larger changes you could create one parent ticket and then a number of subtickets to keep track of the larger picture.

 

I hope that this can be the start of a long running fruitful collaboration and it is always great to see groups like yours come in from the side and start contributing based on the needs and functions you come across.

 

Heartly welcome!

Best

Jørn

 

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

--

[Donald mteka]

Hi Sarah,
Thanks a lot for your +ve feedback.
 That presentation was not  meant to be exhaustive in any way but to help bring some light, actually testing the features with an emulator is really the perfect way anyone would see the features in their own right.
 Also nothing so far has been contributed to the main trunk, and contributing to the development and improvement of software by anyone with the potential to do so has been the  philosophy behind all opensource projects. This involves thorough review by developers already leading the project, as such that  only shows our willingness and desire to contribute to openxdata.
 The review process is clear as Jorn has put it, but remember this is no increment change as it has been worked on for a long time without reference to the original trunk version, too many changes even reviewing a patch would be a daunting task. But we can't expect anything less, we want something that works flawlessly.
 Right from beginning we could be writing tickets, but at some point we had no time to wait until someone from dev-team works it out while we could implement that ourselves, and recently I reviewed what was already in the tickets list, was more than impressed to see that  we have been in the hunt for same features and and many more others..
 
As to your features comments:
2,3)-After saving your data, how is it displayed in data list? When design a form, you define a description template for that, which means it is "hard coded " by the form design. What if no description template is given, you get Data 1, Data 2 ... for that form right?
 Also, how are your repeat data displayed? As a list of all answers, does it feel right? It needs a description template as wel

5,6)- If already there, no crime here, sorry that we have perhaps duplicated the efforts, one us could probably had been spared time to go play games or go skiing instead instead of re-inventing the wheel!!!!!, But again, there is more to chew for developers..

8) Again, because we never brought this much earlier,  nothing more. To the developers, only implementation makes the  deference.

9) Yes, you got it right sarah!. But  you can't design such form in purcforms.
10) Just the way upload response is organized, neater of course.
11)  There even still more implications to be considered, but currently the focus was to make sure you are not locked out!!

Hope that adds something,
Best regards

--
Donald Mteka
+255653105004

[Dagmar Timler]

Hi

To be clear about the process: anyone can create tickets and write patches. These patches will be reviewed and incorporated into the trunk, by the core team, when the requirements and code meet our standards. 

If you need some functionality in the trunk and have someone who can develop the change, it is simple. You should join the process by creating a ticket and patch for review.

Thanks

Dagmar

[Donald mteka]

Hi Jørn,
 Thank you for your feedback. We will be happy to work with the dev team and answer any questions  concerning design decisions and implementation goals. Also, we expect a good guidence towards incorporating any features that pass consensus.  We don't expect anything to put pulled in 'as is' without review. The one thing that makes this different, we were not doing this in the 'openxdata development process'. Rather, it is expected the openxdata-dev team to see what is valuable and pull it into current and future releases and implementations.
 Best regards,
 Donald

--
Donald Mteka
+255653105004

[Donald mteka]

Hi Dagmar,
 Thanks, that is as far as we have come to learn about openxdata development process. That is clear and straight forward. What we mean here is for the openxdata community to see if the features/enhancements we have so far implemented  appeal to them and think that they want them incorporated into releases. So, your standards and whatever requirements can only be realized by the developers who have established their own standards. Thus far, we never worked to meet your standards, it was pure out of our requirements and creativity that we went that far.
 We only want to share this and contribute back to the openxdata project and thus seek collaboration with existing dev-team to see how this can be made to fit into 'their standards'. It could be you(who know the standards) or me(when i know the standards) to raise the code to the standards and requirements.
And what I believe is, standards and creativity are not very good friends.
 Best regards.
 Donald.

[Jørn Ivar Klungsøyr]

Hi Donald,

 

I just want to emphasize that we fully welcome your contributions  and we would like to use this opportunity to bring your group into the development group so that we can synchronize the efforts and innovations :)

 

The process we now have been working on establishing is basically the same as is used by most major open source projects.

 

Best regards,
jørn

 

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

 

[Mayala Mwendesha]

Hi Dagmar
My response in line

On 1/12/12, Dagmar Timler <diggi...@gmail.com> wrote:
> Hi
>
> To be clear about the process: anyone can create tickets and write patches.
> These patches will be reviewed and incorporated into the trunk, by the core
> team, when the requirements and code meet our standards.
>

It is true that anyone can create a ticket and write patches
as Donald said we were working with OpenXdata offline as a result the
source code have changed a lot on our side even though the
functionality remain the same. We removed what we seen as dead code
and what we seen as code doing something could be done by a more
appropriate class.
thinking that we will easy the Developer time to learn and do things
more easily.
If we could create a ticket for this it could introduce some overhead
to programmers that is why we ask you guys to give us a place where we
can upload the source code and developer review them and give their
feed back!

> If you need some functionality in the trunk and have someone who can
> develop the change, it is simple. You should join the process by creating a
> ticket and patch for review.
>

I have not understood your point here! did you mean that we were not
supposed to touch the source code and do some programming instead we
were required to raise a need and you guys develop that need! if so is
OpenxData an open source project?

sorry if i misunderstood your point

[Dagmar Timler]

Hi Mayala

I think you have misunderstood my point. What I was trying to say is that anyone can raise a ticket *and* anyone can submit a patch. You don't need to raise tickets and wait for other developers to implement them if you can do it yourself. That is all.

Thanks

Dagmar

[Daniel Kayiwa]

Hi Mayala,

I first of all thank your team for both the great work you have done and the willingness to share it with others!!! Keep it up!!!

I have responded to your questions inline according to how i understood.

On Thu, Jan 12, 2012 at 4:37 PM, Mayala Mwendesha <mmwen...@gmail.com> wrote:

Hi Dagmar
My response in line

On 1/12/12, Dagmar Timler <diggi...@gmail.com> wrote:
> Hi
>
> To be clear about the process: anyone can create tickets and write patches.
> These patches will be reviewed and incorporated into the trunk, by the core
> team, when the requirements and code meet our standards.
>

It is true that anyone can create a ticket and write patches
as Donald said we were working with OpenXdata offline as a result the
source code have  changed a lot on our side even though the
functionality remain the same. We removed what we seen as dead code
and what we seen as code doing something could be done by a more
appropriate class.
thinking that we will easy the Developer time to learn and do things
more easily.
If we could create a ticket for this it could introduce some overhead
to programmers that is why we ask you guys to give us a place where we
can upload the source code and developer review them and give their
feed back!

 

On the contrary, creating a ticket and attaching the corresponding patch based on the current OXD's trunk would greatly simplify the task of the core developers and result into a faster incorporation of your great innovations into the OXD releases.
In addition to this, the ticket will also do a good job of keeping a record of the discussions from the rest of the community concerning the particular issue that the ticket addresses. So all the feedback you need from both the developers and non developers would be on this ticket as a form of organizing feedback per issue.

> If you need some functionality in the trunk and have someone who can
> develop the change, it is simple. You should join the process by creating a
> ticket and patch for review.
>

I have not understood your point here! did you mean that we were not
supposed to touch the source code and do some programming instead we
were required to raise a need and you guys develop that need! if so is
OpenxData an open source project?

sorry if i misunderstood your point

You can read from the past threads in which this process was agreed upon by the community and you will see that it is the same thing done with all other open source projects. When you create the ticket and submit the patch for review, you are contributing and indirectly touching the source code because when the patch is approved and applied, you will see your changes in a way not different from the core committers. But with time, as you continue to submit patches, you can be voted to become a core committer and hence not require any more using of patches.

--
If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

[Mark Gerard]

@Jørn and everyone,

From a TCC point of view, this code will have to go through the metrics that all other code goes through. I think that is the point Dagmar is making.

We do not want to stretch the already constrained resources reviewing a branch (which we might not actually leverage). I am trying to be careful here, the functionality you added is *GREAT* and there is no doubt that we could use some of the features you added, but we want to make that transition as simple as possible, respecting everyone and making sure we do not go off as giving priority to you. 

Whatever changes that you made in the offline mode, they will have to be merged with the latest trunk and later pushed as patches (there is absolutely no way around this however way you slice it) that can be reviewed and submitted to trunk, anything less than that is going to create a back and forth scenario that might end up frustrating these noble efforts.

I would concur with Dagmar that you create a ticket for every feature/dead code/enhancement etc that you worked on, create a patch that only addresses the context of that ticket and submit it for review. This will have to be done in the regular iteration process (meaning you participant in the iteration planning meeting and the sprints -- of course respecting the priority accorded to the tickets from the management point of view) - the reason is that this process accords us the ability to trust that we are on the same page.

Dont think for a second that I am against this effort. No! But we are so constrained now that we hardly review our patches in the timelines that we desire. With this scenario, think about how long it will take to review a branch from a technical perspective, let alone from a QA perspective (even the business analysts we have now are strained).

I am trying to be as pragmatic as I can.

Mark

[Mayala Mwendesha]

Hi All,

Thanks for the clarification you gave.

From those point I can now see why their is a need for tickets for this patches.

On the other hand we asked Brent the best way to submit these changes and he told us that since we added some new class and new methods and removed some classes from the trunk source code it could be better if we submit it as a separate so that people can see why we removed or added a new class and come up with a way forward if we can go on submitting a ticket for the changes to be incorporated in the normal way.

On our side we thought it could also build a trust from you developers that what is being done from this side is good and trusted!

Regards
Mayala Mwendesha  CCNA, ITILv3, PMP

[Mark Gerard]

I will just mention that neither Brent nor Jørn (or anyone for that matter) *directly* influences what goes into the code base. There is a transparent way that is done which everyone has to get acquainted to. In the past, we have operated in "free mode" where by everyone and everything hits the repo - the results of that are better left undiscussed for now. This process is what Dagmar labored to explain in the earlier communication.

The process is described here: https://trac.openxdata.org/wiki/ProcessChanges

and here: https://trac.openxdata.org/wiki/ProcessImprovements

This is how it works:

1. A ticket is made(feature,task,bug,enhancement)

2. People in the community vote on that ticket (it usually goes to the top). See the backlog here: https://trac.openxdata.org/backlog/milestone/Server-1.X

3. A developer signs up for that particular ticket during a sprint (we use a top down approach where the prioritized tickets are worked on first)

4. After working on it, a patch is submitted

5. The patch is reviewed by a TCC member who then commits it.

6. After a successfully commit, it is sent to QA which later decides whether to close it or not!

Look here: https://trac.openxdata.org/attachment/wiki/TracPatchWorkflow/patch-review-workflow.png

If Brent gave you the impression (which I doubt he did because you might have misunderstood him, he introduced this process), then he was wrong. We are trying to be like many successful open source projects and are borrowing heavily from processes used at Apache. So either way, you would have to go through this process and the code would be subjected to the same transparent community metrics like all the other code. 

Now that we are clear and agree on the process, let us stop the discussion and create the tickets.

Thanks

Mark

P.S: All those links were written by Brent - that is why I think you misunderstood!

[Jørn Ivar Klungsøyr]

Hi,

 

I think the points needed to be raised about the process in relation to the original email have been raised, so I hope we can focus on what Donald and Mayala have worked on and from there consider what functions/features/improvements that could be scheduled for later versions of openXdata – through the processes that have been well elaborated in this thread :)

 

The code Donald and Mayala have worked on will be uploaded to a repo under Experimental – so that the work done is retained and available and differences from original revisions are identifiable. This does not imply anything else than that Donald and Mayala are sharing their work with the community. A message will be sent to the group once it is there.

@Mark, what you have written here is a nice start for a write-up that could be used as an introduction on trac for how things are working as of today.

 

Best regards,

Jørn

 

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

 

From: openxd...@googlegroups.com [mailto:openxd...@googlegroups.com] On Behalf Of Mark Gerard
Sent: Thursday, January 12, 2012 9:21 PM
To: openxd...@googlegroups.com
Subject: Re: [openXdata-dev] FEATURES AND ENHANCEMENTS FOR OPENXDATA MOBILE CLIENT

 

 

I will just mention that neither Brent nor Jørn (or anyone for that matter) *directly* influences what goes into the code base. There is a transparent way that is done which everyone has to get acquainted to. In the past, we have operated in "free mode" where by everyone and everything hits the repo - the results of that are better left undiscussed for now. This process is what Dagmar labored to explain in the earlier communication.

[Mayala Mwendesha]

Hi Mark,

Once again thanks as I said we have understood your points and concern and we vote a +1 for. 

Reading your mail it seem as if you are misunderstanding us that we are not ready to follow the standard and procedures agreed with OpenXdata developers. But the fact remain we are ready to follow them from the first move. That is why we took an initiative  to ask!

Let us focus on what you said and what Jorn said

Thanks for your time once more.

Regards.

Mayala Mwendesha  CCNA, ITILv3, PMP 

[Dagmar]

Let's focus on the next steps.

1. Upload codebase to experimental directory in svn. Merely for comparison with current mforms trunk. How does

One get access?

2. Create tickets for features that we would like to see in trunk. I am not the best person to do this although I am happy to create the tickets given a list. I believe there is already one for partially saved forms.

3. Create patches that can be applied to the trunk. I would imagine the original developer should do that otherwise it would be a needle in a haystack job and I would most likely choose just to redevelop myself from scratch.

4. Review and apply patches. This is where I see myself being able to help the most.

Kind regards

Dagmar

[Jørn Ivar Klungsøyr]

Thanx Dagmar,

 

I’ve made two branches of the revisions they used as starting point and we’re working on uploading the changes to that branch.

https://svn.openxdata.org/Experimental/DeveloperTestBed/DonaldMteka/

Will notify the group once done.

 

Will also setup a test instance so others can test the functionalities.

 

All registered devs have write permissions on the Experimental subtree in subversion (and everyone has read permissions on everything…..).

 

Best

jørn

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

 

[Mark Gerard]

+1

Mark

[Jørn Ivar Klungsøyr]

Hi all,

 

The code Donald and Mayala have worked on is now available at:

https://svn.openxdata.org/Experimental/DeveloperTestBed/DonaldMteka/

 

You may also easier see changes with diff in trac from this URL:
https://trac.openxdata.org/log/Experimental/DeveloperTestBed/DonaldMteka

 

I have also uploaded a binary version of server to:

http://demo.openxdata.org/exp_dm_mm

 user: admin

pass: openXdata

 

Attached is a zip with the mobile jar/jad that you can try.

Make sure you update the URL according to the URL above.

 

Best regards,

Jørn

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

 

From: openxd...@googlegroups.com [mailto:openxd...@googlegroups.com] On Behalf Of Donald mteka

Sent: Thursday, January 12, 2012 7:55 AM
To: openxdata-dev

--

[Sarah Bird]

Hi all,

I've had a look focussed on the mobile client

Some general points:
1) Nice idea on the connection settings, but I think the new connection settings dialog that is on trunk is more stable than what is in this client (for example, if you modify defaults.properties and set to http://demo.openxdata.org/exp_dm_mm then the application completely crashes as there's no port number)
2) I don't think we need to incorporate the first opening message
3) I really like the new red icon - if it doesn't cost anything in performance on low-end phones I would recommend we change
4) I really like the way that clicking on the repeat question for the first time automatically opens it up for you to immediately add a new response - speeds up users interaction with the form
5) I don't like the editing the description template for the repeat question or for the form - i feel that it slows down the users interaction and is confusing - I can also imagine, but don't know, that it adds overhead when re-downloading forms to edit data. Generally, I would say that users are going to be interacting with lots of forms rather than one form with lots of repeat answers so this seems like misplaced user control -> if you have that many repeats per form, it would probably be safer to save multiple forms along the way rather than risking losing data if the phone crashed or something - however, with the ability to do partially saved forms maybe that's no longer true ... anyway i'm rambling - i still don't see how this is useful given the slowdown and potential confusion it brings -> it brings in a new thing the user has to learn about the app rather than focusing on the form. Despite clicking patientID, I managed to to save a form with no description so I have a blank list which actually has my responses in. I also found that every time i clicked through a field it added it to the list rather than replaced. Not meaning to go on - Overall, in my opinion, this is functionality for an admin / study manager not for a data collector - therefore doesn't belong on the mobile client - would love it if it was this easy to define the Form description through the web interface though (now you need to have to be a little nerdy to make it work). Furthermore, by being on the mobile client it slows down the users interaction with the form, so it's a double no for me.
6) I like that the form view shows the number of responses given to the repeat question rather than a list of the responses - tidier and sufficient (I also think the use of square brackets to denote this as opposed to curly brackets for data was smart)
7) The Mark for Upload didn't work for me - when I did mark for upload and then go to the Study level and select upload data all the data was uploaded. Regardless I think this is overkill, we have an opportunity for individual or bulk upload and I think that you can have too much functionality
8) There is no upload log, that is a good new addition we've got
9) The updated upload screen is not working well for me - see attached photo (SAM_0009.JPG) - however if I'm imagining what it should be like correctly, I like the list with a tick icon and then selecting the form for further info - it is a good use of space for the small screen.
10) I couldn't save a partially filled form when I hadn't entered any data - it kept saying "Save complete study is full" over and over and I had to quit although when I logged back in it appeared to be saved - partial form saving is now implemented in main trunk anyway
11) The invalidate data function did not seem to affect the status of data on the server
12) Overall I like the get data functionality. It took a little getting used to but it is good - i think a version of it would be a good upgrade to our existing download data functionality
13) Didn't test the deep repeat

Nice work.

A while back Dine had started to create tickets based on the work, maybe we can incorporate some of these thoughts if others agree.

Cheers,

Bird

[Donald mteka]

Hi all,
 Thanks a  lot, Sarah, for your feedback!. It gave me an idea of what a first time user will go through. You gave very good tips on pitfalls. But here follows some in-line responses to throw some light where you found darkness and appreciate your appreciations...

Some general points:
1) Nice idea on the connection settings, but I think the new connection settings dialog that is on trunk is more stable than what is in this client (for example, if you modify defaults.properties and set to http://demo.openxdata.org/exp_dm_mm then the application completely crashes as there's no port number)

  Thanks for the 'test case', I see why it crashes... When parsing the url, the implementation expects a port to be there. But the whole world knows that you need not say ':80'. Fix to come.

2) I don't think we need to incorporate the first opening message

 The intention is to give the first time user the idea of what is needed to quick start before you actually popping up settings dialogs. You have your say..

3) I really like the new red icon - if it doesn't cost anything in performance on low-end phones I would recommend we change

  Probably the cost could have been colors and file size, but a star icon and a red icon are both colored. On file size, tried to shrink the red icon down to 376 bytes compared to 300 bytes of a star icon.. Does that really count?

4) I really like the way that clicking on the repeat question for the first time automatically opens it up for you to immediately add a new response - speeds up users interaction with the form

   ;-)

5) I don't like the editing the description template for the repeat question or for the form - i feel that it slows down the users interaction and is confusing - I can also imagine, but don't know, that it adds overhead when re-downloading forms to edit data. Generally, I would say that users are going to be interacting with lots of forms rather than one form with lots of repeat answers so this seems like misplaced user control -> if you have that many repeats per form, it would probably be safer to save multiple forms along the way rather than risking losing data if the phone crashed or something - however, with the ability to do partially saved forms maybe that's no longer true ... anyway i'm rambling - i still don't see how this is useful given the slowdown and potential confusion it brings -> it brings in a new thing the user has to learn about the app rather than focusing on the form. Despite clicking patientID, I managed to to save a form with no description so I have a blank list which actually has my responses in. I also found that every time i clicked through a field it added it to the list rather than replaced. Not meaning to go on - Overall, in my opinion, this is functionality for an admin / study manager not for a data collector - therefore doesn't belong on the mobile client - would love it if it was this easy to define the Form description through the web interface though (now you need to have to be a little nerdy to make it work). Furthermore, by being on the mobile client it slows down the users interaction with the form, so it's a double no for me.

 Oooooops, a big bump!. And a very useful one! will try to explain in as many words and may be more just to get everybody the idea..
  The idea is....
  Way back to openxdata 1.3.4, the sample study form had a description template which displayed data as '{lastname} in {continent}' (No longer there in latest releases). eg. if you entered a data for lastname as Michael and continent Africa, it is displayed as 'Michael in Africa' in form data list. That's is very intuitive to the data collector when he looks at the list of data he has in hand! He can quickly tell which data is which!
So, as a data collector, what happens when:
  1) the form designer (aka study admin/manager) didn't enter a description template
         =>You get data displayed as Data: 1, Data: 2, Data:3 ........... etc.
     Good enough?, Or how do you compare that to 'Michael in Africa'?
  2)the description template, to you, doesn't fit well with what makes sense of the data you are collecting or does not include some important detail.
       =>A frowning may somehow do you good, at least, to show your dissent.
         You may not tell the study manager to change it to something that suits you, unless you are the only data collector.
     So suppose you participating in a global survey and you are in Africa, particular in Tanzania. Obviously saying Michael is in Africa (or Tanzania for that matter) isn't that helpful.
      What if you want the patient's  town to show in a description, or their phone number?
  The mission was to FREE THE DATA COLLECTOR from this Study manager's brain LOCK IN!
  How? The is only one way out. PASS THE CONTROL TO THE DATA COLLECTOR.
 
 Up to this point your views shows that, may be, having data displayed in a style you want, or contain some information you need is not as useful as one would think.
  But if at some point you think it could be useful, then here are some guides which will either automate it, or improve it..
  1)  As of now, the current implementation (yours at the demo is already old!) assumes the description template proposed by the form design  is sufficient.  You are not forced/asked to to edit edit!
    The downside side of this? It is may turn out to be a hidden feature... But it's far better than being forced to edit one.
  2)If no template is given at all, sorry you have to tell the app how to show your entered data. Edit the template. Unfortunately this is going to happen for any repeat question as there no such feature in the form designer ( some one should open a  ticket to add it should this feature make it through!). So the study manager won't help you with that anyway!
    This is a first time only stuff!
  Now, interestingly, just when I am writing this email, an idea came on how to improve this last case (which might have made us speak at the top of our volumes!!!)
  WHY NOT CREATE  THE DESCRIPTION TEMPLATE FOR THE USER BY PICKING SOME FEW RANDOM QUESTIONS?
 One, or may be two! (including at least one mandatory question so that the user actually sees the data displayed and not empty fields, though this is no longer avoidable with the saving partial forms feature and we may be going back to list as Data: n).
Are you still of the same opinion dear Sarah!?
  And concerning downloading data, rest assured it has nothing much to do with that!

6) I like that the form view shows the number of responses given to the repeat question rather than a list of the responses - tidier and sufficient (I also think the use of square brackets to denote this as opposed to curly brackets for data was smart)

  And when you want to see the repeat data, you should likewise see the tidier list of repeat data (if the description template thing didn't kill you!). The repeat data list used to contain a comma separated list of all questions. Imagine a repeat question with 10 questions!!!!!.

7) The Mark for Upload didn't work for me - when I did mark for upload and then go to the Study level and select upload data all the data was uploaded. Regardless I think this is overkill, we have an opportunity for individual or bulk upload and I think that you can have too much functionality

  I see. When you mark data for upload, an immediate action is expected! Any act of navigating back assumes you changed your mind!
 An overkill?? Mmmh, look at it this way:
  1) The feature is consistent at study list level, form list level and form data list level! that sums up to just one functionality to the use (just given more options if he desires!)
  2)You have only two options in sending data as of now, (a) SEND EVERY THING (b) SEND ONE INDIVIDUAL DATA AT A TIME.
    What you get from that feature is HOW BULK IS BULK? Is it
    (a) ALL STUDIES/FEW SELECTED STUDIES
    (b)ALL FORMS IN A STUDY/ FEW SELECTED FORMS IN A STUDY
    (c)ALL DATA IN A FORM/ FEW SELECTED DATA IN A FORM
    That makes up to how many options? Simple math, 3x2=6.
   Don't tell me you never wanted to upload data of some form because you are done, but others should stay?.

    
8) There is no upload log, that is a good new addition we've got

   This was our first solution to enable a data collector to get the chance to take some action on the data he submitted from the mobile app! He only had to select a particular log and take the action!
   But where are we know? The get data feature kills the game.. No need of logs which just takes up space.. When you get data, you actually get a log! From that, it is to you decide what do you do with that, delete, invalidate, do a full download.
  And of course when you delete it from the phone, you can get it again next time you want It!
  Do you see any room for upload log? Dead and gone..

9) The updated upload screen is not working well for me - see attached photo (SAM_0009.JPG) - however if I'm imagining what it should be like correctly, I like the list with a tick icon and then selecting the form for further info - it is a good use of space for the small screen.

   I have seen your screen shot. Jorn should acknowledge that I sent him some two patches to apply to fix it even before he posted the notification mail.. It is just  that the lines a too long and I forgot to set a line-wrap option for that display screen! I guess he deployed the jars are sent him, nothing much.

 
10) I couldn't save a partially filled form when I hadn't entered any data - it kept saying "Save complete study is full" over and over and I had to quit although when I logged back in it appeared to be saved - partial form saving is now implemented in main trunk anyway

     Huuuuh, save form without even entering any data? Sounds a good tip for stability..
    I tested the latest mforms on the trunk on thursday before I gave a spin on Brent's mforms-2.0. I noted it is now implemented, but is a way behind the way i implemented with one BIG DIFFERENCE.
   The current implementation wont allow you to send bulk  data if any form is not completely answered.. In my implementation, the incomplete form(s) stay. And technically, there was a lot to change to get this feature to work that way.

11) The invalidate data function did not seem to affect the status of data on the server

   Did you look at the underlying form_data tables and export table? There are notable differences and no doubt you were looking for a void flag in form_data table. But actually the generated export table has a column   named data_valid, has to be on or off! This is so to have  grained control of exactly what you want to invalidate, it could just one repeat data! Infact, the data Id you see in the log, is an actual entry id in the exported table. Should have noted that the primary keys are integers rather that UUID strings. The motivation to change into integers  was that this Id needs to be  included in an sms to users, a UUID string would cost too many charaters! I don't think this will play very well with current UUID deployments, unless no one is using the Id for an future reference, in which case it could be replace with integers with change to the rest of state of matters.

12) Overall I like the get data functionality. It took a little getting used to but it is good - i think a version of it would be a good upgrade to our existing download data functionality

 :-)

13) Didn't test the deep repeat

   I didn't either! Why? The heavy lifting have to be done on the form designer to exploit it. But even so, in this implementation,
   The REPEAT QUESTION DEFINITION  is just another FORM DEFINITION! What does that mean? Simple proof by induction,
   =>what works with form definition, should work with repeat question definition-> in a repeat question  definition->in a repeat question definition->in a repeat question definition.....................................
 But should be testable through junit by making up some hypothetical formdef.

 It's hard not to say i am so impressed with your views. My general perception is that you stumbled  at some points because it was not clear from the outset, what was meant for what! But that's exactly how the end users will approach the application. So, the user is not the one to blame where he finds it difficulty or clumsy!
  Thanks everyone for following this.
  HTH,
  Donald

Donald Mteka
+255653105004

[Sarah Bird]

Hi Donald some further thoughts in blue:

On Sun, Feb 26, 2012 at 11:12 PM, Donald mteka <donal...@gmail.com> wrote:

Hi all,
 Thanks a  lot, Sarah, for your feedback!. It gave me an idea of what a first time user will go through. You gave very good tips on pitfalls. But here follows some in-line responses to throw some light where you found darkness and appreciate your appreciations...

Some general points:
1) Nice idea on the connection settings, but I think the new connection settings dialog that is on trunk is more stable than what is in this client (for example, if you modify defaults.properties and set to http://demo.openxdata.org/exp_dm_mm then the application completely crashes as there's no port number)

  Thanks for the 'test case', I see why it crashes... When parsing the url, the implementation expects a port to be there. But the whole world knows that you need not say ':80'. Fix to come. 

if you're interested there was another problem that if you start typing in simple and switch to advanced what you wrote isn't saved - i wouldn't bother fixing this or the previous - the existing functionality in trunk handles this just fine so i would incorporate that code

2) I don't think we need to incorporate the first opening message

 The intention is to give the first time user the idea of what is needed to quick start before you actually popping up settings dialogs. You have your say..

my experience of implementations is that you hand the user (usually many users) the phone all setup - their job is not to configure an app but to collect data

3) I really like the new red icon - if it doesn't cost anything in performance on low-end phones I would recommend we change

  Probably the cost could have been colors and file size, but a star icon and a red icon are both colored. On file size, tried to shrink the red icon down to 376 bytes compared to 300 bytes of a star icon.. Does that really count?

i have no idea - something for the devs

yeah, i disagree :D i just don't see the predominant use case for openxdata being the scenario you're describing. i see the mobile client as being a tool to collect data. the methodology for how to collect that will usually have been specified by an organization or project, training will have been given on the app and the forms and how the forms will appear to the user while they are using the app. so i'm not sure that allowing the user to change that helps the user in general and it definitely doesn't if it slows them down or creates whole new failure points. imagine you're running a survey with 200 data collectors and you have 20 forms. and you've given them the power to change that - how will you help them troubleshoot remotely when every user could be looking at something different?

I like the fact that you are seeing it from the data collectors point of view who may want to change it to something that is more conducive for their work and their boss is not willing to change it. I can see that perspective, I wouldn't want to run an implementation with that kind of variability. But I do think its a good perspective and I think that this should be thrown out to others to chip in on.

6) I like that the form view shows the number of responses given to the repeat question rather than a list of the responses - tidier and sufficient (I also think the use of square brackets to denote this as opposed to curly brackets for data was smart)

  And when you want to see the repeat data, you should likewise see the tidier list of repeat data (if the description template thing didn't kill you!). The repeat data list used to contain a comma separated list of all questions. Imagine a repeat question with 10 questions!!!!!.

As I said, it did kill me :D but I totally agree about the "imagine a repeat question with 10 questions" and I would like to see the "description template" implemented at the server level for both forms and repeat questions

7) The Mark for Upload didn't work for me - when I did mark for upload and then go to the Study level and select upload data all the data was uploaded. Regardless I think this is overkill, we have an opportunity for individual or bulk upload and I think that you can have too much functionality

  I see. When you mark data for upload, an immediate action is expected! Any act of navigating back assumes you changed your mind!
 An overkill?? Mmmh, look at it this way:
  1) The feature is consistent at study list level, form list level and form data list level! that sums up to just one functionality to the use (just given more options if he desires!)
  2)You have only two options in sending data as of now, (a) SEND EVERY THING (b) SEND ONE INDIVIDUAL DATA AT A TIME.
    What you get from that feature is HOW BULK IS BULK? Is it
    (a) ALL STUDIES/FEW SELECTED STUDIES
    (b)ALL FORMS IN A STUDY/ FEW SELECTED FORMS IN A STUDY
    (c)ALL DATA IN A FORM/ FEW SELECTED DATA IN A FORM
    That makes up to how many options? Simple math, 3x2=6.
   Don't tell me you never wanted to upload data of some form because you are done, but others should stay?.

Hi, yes, I think you can have too much functionality and whilst I understand your reasoning I think this is adding marginally useful functions at the expense of usability - sorry :)

8) There is no upload log, that is a good new addition we've got

   This was our first solution to enable a data collector to get the chance to take some action on the data he submitted from the mobile app! He only had to select a particular log and take the action!
   But where are we know? The get data feature kills the game.. No need of logs which just takes up space.. When you get data, you actually get a log! From that, it is to you decide what do you do with that, delete, invalidate, do a full download.
  And of course when you delete it from the phone, you can get it again next time you want It!
  Do you see any room for upload log? Dead and gone..

Hi I actually do see a use case for a log - it's been implemented and the ticket outlines it. In short, it came up in Peru, data collectors come back to head office every few days and check in with their supervisor. They need to compare a list of what they believe they've collected and uploaded with what's been received on the server. This serves as a check and balance to ensure all data is present. The upload log provides this feature. Getting data back from the server doesn't fulfill this use case.

9) The updated upload screen is not working well for me - see attached photo (SAM_0009.JPG) - however if I'm imagining what it should be like correctly, I like the list with a tick icon and then selecting the form for further info - it is a good use of space for the small screen.

   I have seen your screen shot. Jorn should acknowledge that I sent him some two patches to apply to fix it even before he posted the notification mail.. It is just  that the lines a too long and I forgot to set a line-wrap option for that display screen! I guess he deployed the jars are sent him, nothing much.

 
10) I couldn't save a partially filled form when I hadn't entered any data - it kept saying "Save complete study is full" over and over and I had to quit although when I logged back in it appeared to be saved - partial form saving is now implemented in main trunk anyway

     Huuuuh, save form without even entering any data? Sounds a good tip for stability..
    I tested the latest mforms on the trunk on thursday before I gave a spin on Brent's mforms-2.0. I noted it is now implemented, but is a way behind the way i implemented with one BIG DIFFERENCE.
   The current implementation wont allow you to send bulk  data if any form is not completely answered.. In my implementation, the incomplete form(s) stay. And technically, there was a lot to change to get this feature to work that way.

I think that the feature of bulk upload functioning but leaving incompletes behind sounds very good and i would like to see it on our trunk

11) The invalidate data function did not seem to affect the status of data on the server

   Did you look at the underlying form_data tables and export table? There are notable differences and no doubt you were looking for a void flag in form_data table. But actually the generated export table has a column   named data_valid, has to be on or off! This is so to have  grained control of exactly what you want to invalidate, it could just one repeat data! Infact, the data Id you see in the log, is an actual entry id in the exported table. Should have noted that the primary keys are integers rather that UUID strings. The motivation to change into integers  was that this Id needs to be  included in an sms to users, a UUID string would cost too many charaters! I don't think this will play very well with current UUID deployments, unless no one is using the Id for an future reference, in which case it could be replace with integers with change to the rest of state of matters.

i didn't look into this deeply, i will take your word for it
 

12) Overall I like the get data functionality. It took a little getting used to but it is good - i think a version of it would be a good upgrade to our existing download data functionality

 :-)

13) Didn't test the deep repeat

   I didn't either! Why? The heavy lifting have to be done on the form designer to exploit it. But even so, in this implementation,
   The REPEAT QUESTION DEFINITION  is just another FORM DEFINITION! What does that mean? Simple proof by induction,
   =>what works with form definition, should work with repeat question definition-> in a repeat question  definition->in a repeat question definition->in a repeat question definition.....................................
 But should be testable through junit by making up some hypothetical formdef.

 

 It's hard not to say i am so impressed with your views. My general perception is that you stumbled  at some points because it was not clear from the outset, what was meant for what! But that's exactly how the end users will approach the application.

 

So, the user is not the one to blame where he finds it difficulty or clumsy!

:D indeed :D

I think the next step for you is to start creating tickets against some of this discussion. These tickets will then be prioritized and start to be implemented into trunk. Thanks for all your work so far!

 

[Donald mteka]

Hi Sarah,
 You just said something beautiful and true, we let others chip in on because we are not the only players!, and though our views could be of value, they don't dictate acceptance or rejection of something. This is a community!
  I like that we had a good share of thoughts and reasoning, and would just throw you to some greened points down there.

  Just one thing to get it right here, and this is  mainly for the devs.. About tickets :)

  =>We shared the ideas when we showed how something works/should work
  =>We also shared the work by giving the source code

  I agree that your system of getting features into the trunk is through the ticketing system. That's how things work, and anybody coming into this community should undoubtedly abide to this steps. No exceptions.

  But when you take a look at the state of things:
  This is a system that calls more for testing. Your are writing tickets for what is already implemented. Not sure where you are heading. I thought rigorous tests would do a big saving.  But this rests in the hands of the devs, they may find it easier to incorporate the features into the trunk by implementing one feature at a time (one may  opt not to even bother taking a look at how it is actually done!). So my 100% cooperation is to digest the implementation with devs, to the degree that every dev who has a good grip on mobile client implementation is comfortable with their understanding. But this just simplifies the process of understanding some implementation logics, you don't need me when you have the source code, unless if you think you need some explanation on how some piece of code works only to save your time!. At that point, they can approve of its quality and cast their vote.
  It is a situation much like Brent' trunk, only  that brent doesn't touch the end user that much, it makes no deference to the end user whether your implementation use RPN expressions or Condition class, but for the devs, THINK TWICE.
 Also brent's work is easily isolated from the rest of system flow(other places are largely renaming). But with this, ther  are very few untouched corners, so you need to have both of your eyes open!

 But what is more important, is that, it is a work based on your work! Your not throwing away anything. Only that there are tweaks and creative thoughts which might have made it even better!!!
 If you are not eager to peep into how others have transformed your work, you are missing the rewards of open source!
 
Thanks again Sarah and I hope that your experience will lead us to be creative in a way that really helps the end user and
 make sure that openxdata is the first choice data collection platform.
 Regards,
 Donald

On Mon, Feb 27, 2012 at 10:43 AM, Sarah Bird <sb...@alum.mit.edu> wrote:

Hi Donald some further thoughts in blue:

On Sun, Feb 26, 2012 at 11:12 PM, Donald mteka <donal...@gmail.com> wrote:

Hi all,
 Thanks a  lot, Sarah, for your feedback!. It gave me an idea of what a first time user will go through. You gave very good tips on pitfalls. But here follows some in-line responses to throw some light where you found darkness and appreciate your appreciations...

Some general points:
1) Nice idea on the connection settings, but I think the new connection settings dialog that is on trunk is more stable than what is in this client (for example, if you modify defaults.properties and set to http://demo.openxdata.org/exp_dm_mm then the application completely crashes as there's no port number)

  Thanks for the 'test case', I see why it crashes... When parsing the url, the implementation expects a port to be there. But the whole world knows that you need not say ':80'. Fix to come. 

if you're interested there was another problem that if you start typing in simple and switch to advanced what you wrote isn't saved - i wouldn't bother fixing this or the previous - the existing functionality in trunk handles this just fine so i would incorporate that code

     The first one needs fix, the second is an 'improvement' to let you switch between simple/advanced without loosing previous contents. The settings a saved when you hit the ok button, has to change.
  +1

2) I don't think we need to incorporate the first opening message

 The intention is to give the first time user the idea of what is needed to quick start before you actually popping up settings dialogs. You have your say..

my experience of implementations is that you hand the user (usually many users) the phone all setup - their job is not to configure an app but to collect data

So, that how it works (at least in most cases)?. We thought we would like to let someone out there whom we have verified his identity (through various means, we may not be able to reach him physically), and has a GPRS, java-enabled mobile phone (or given funds to get all needed tools)  to participate in our research and should get some direction in our absence. All he needs is point his url to openxdata.org to get the mobile client and use the credentials we sent him. But all in all, it's just a 'friendly way' of getting someone started, nothing much..

      Well said Sarah, others' turn to weigh this out.

6) I like that the form view shows the number of responses given to the repeat question rather than a list of the responses - tidier and sufficient (I also think the use of square brackets to denote this as opposed to curly brackets for data was smart)

  And when you want to see the repeat data, you should likewise see the tidier list of repeat data (if the description template thing didn't kill you!). The repeat data list used to contain a comma separated list of all questions. Imagine a repeat question with 10 questions!!!!!.

As I said, it did kill me :D but I totally agree about the "imagine a repeat question with 10 questions" and I would like to see the "description template" implemented at the server level for both forms and repeat questions

   +1

7) The Mark for Upload didn't work for me - when I did mark for upload and then go to the Study level and select upload data all the data was uploaded. Regardless I think this is overkill, we have an opportunity for individual or bulk upload and I think that you can have too much functionality

  I see. When you mark data for upload, an immediate action is expected! Any act of navigating back assumes you changed your mind!
 An overkill?? Mmmh, look at it this way:
  1) The feature is consistent at study list level, form list level and form data list level! that sums up to just one functionality to the use (just given more options if he desires!)
  2)You have only two options in sending data as of now, (a) SEND EVERY THING (b) SEND ONE INDIVIDUAL DATA AT A TIME.
    What you get from that feature is HOW BULK IS BULK? Is it
    (a) ALL STUDIES/FEW SELECTED STUDIES
    (b)ALL FORMS IN A STUDY/ FEW SELECTED FORMS IN A STUDY
    (c)ALL DATA IN A FORM/ FEW SELECTED DATA IN A FORM
    That makes up to how many options? Simple math, 3x2=6.
   Don't tell me you never wanted to upload data of some form because you are done, but others should stay?.

Hi, yes, I think you can have too much functionality and whilst I understand your reasoning I think this is adding marginally useful functions at the expense of usability - sorry :)

    Throwing the ball to others

8) There is no upload log, that is a good new addition we've got

   This was our first solution to enable a data collector to get the chance to take some action on the data he submitted from the mobile app! He only had to select a particular log and take the action!
   But where are we know? The get data feature kills the game.. No need of logs which just takes up space.. When you get data, you actually get a log! From that, it is to you decide what do you do with that, delete, invalidate, do a full download.
  And of course when you delete it from the phone, you can get it again next time you want It!
  Do you see any room for upload log? Dead and gone..

Hi I actually do see a use case for a log - it's been implemented and the ticket outlines it. In short, it came up in Peru, data collectors come back to head office every few days and check in with their supervisor. They need to compare a list of what they believe they've collected and uploaded with what's been received on the server. This serves as a check and balance to ensure all data is present. The upload log provides this feature. Getting data back from the server doesn't fulfill this use case.

      They really needed that? Why such cross-checking? This is an electronic system. Its operation can be guaranteed and we can tell whether the data made it through to the server or not. No cheats/lies. So if i delete the log entry of some (intentionally wrong) data and deny to have sent such data, what do they do? Lie detectors could save a day!!!!!!!!

9) The updated upload screen is not working well for me - see attached photo (SAM_0009.JPG) - however if I'm imagining what it should be like correctly, I like the list with a tick icon and then selecting the form for further info - it is a good use of space for the small screen.

   I have seen your screen shot. Jorn should acknowledge that I sent him some two patches to apply to fix it even before he posted the notification mail.. It is just  that the lines a too long and I forgot to set a line-wrap option for that display screen! I guess he deployed the jars are sent him, nothing much.

 
10) I couldn't save a partially filled form when I hadn't entered any data - it kept saying "Save complete study is full" over and over and I had to quit although when I logged back in it appeared to be saved - partial form saving is now implemented in main trunk anyway

     Huuuuh, save form without even entering any data? Sounds a good tip for stability..
    I tested the latest mforms on the trunk on thursday before I gave a spin on Brent's mforms-2.0. I noted it is now implemented, but is a way behind the way i implemented with one BIG DIFFERENCE.
   The current implementation wont allow you to send bulk  data if any form is not completely answered.. In my implementation, the incomplete form(s) stay. And technically, there was a lot to change to get this feature to work that way.

I think that the feature of bulk upload functioning but leaving incompletes behind sounds very good and i would like to see it on our trunk

    But I liked the incompletes being marked with red, will soon get it on..

--
Donald Mteka
+255653105004

[Dagmar Timler]

I'm sorry I can't possibly read all the text in this email chain, so apologies in advance if I am repeating.

Sarah, 

on your point 5:

There is already a description template which can be set in the form designer. We should use that instead of adding complex functionality into the mobile client.

all other points I agree with your analysis.

Thanks

Dagmar

[Sarah Bird]

Hi,

On point 5, to make sure we're being clear.

Whilst I wouldn't want it in the mobile client, what I liked about what Donald had done was he'd made it easier to set the description template. I was suggesting we add a little feature into form designer to make it easier for users to set the description template in the form designer rather than having to manually type $binding$.

Cheers,

Bird

[Brent Atkinson]

Hi,

Yes, lots of text...

I would love to get these into Trac whether we're going to do them or not. We get the requests documented and searchable in the issue tracker and we can discuss and accept/reject these separately.

Also, Donald, did you say something about Trac being for existing functionality? If you did, that's not the case. The group was just barely using Trac until recently, but the intent is to use it for all work and our processes now reflect that.

The sooner these get into Trac, the better.

Brent

[Dagmar Timler]

Good idea, and thanks for the summary.