i'm going to try to take this one at a time...
And I'm not sure I'm totally groking the UI. I'm looking at this from what
might be a naive user. I down loaded the form and then it took me some time
to find the right actions to get to I guess what is the home screen of the
application.
agreed. we can make this a little easier. perhaps a tutorial on first
launch explaining core functionality or showing a quick video may be
useful. if folks want this, please file a feature request.
So I hit Start New Form and it takes me to a new page with the
form name but doesn't tell me anything. The menu button doesn't do anything
but then I hit the form name and it pops up a splash screen and then takes
me to yet another screen which tells me the form is loaded but that I have
to swipe to actually get to start inputting data. Looks like the front end
overhead of just starting for each form entry might be 100% or more
depending on the form. I suppose this is all because you might have more
than one form loaded.
you suppose correctly. we built odk to support multiple forms at a
time. the interaction you experienced of selecting an item from a list
is a standard android thing. ditto with the not knowing if there is a
menu button. form specific splash screens teach users about the swipe
interaction and are designed so organizations can brand each form
without branding the entire application. i'm pretty sure we tried
jumping directly to the first question in the old days and decided
against it. maybe carl remembers the reason why. i suppose this could
change at some point if lots of people wanted it.
On the back end of the form I'm not sure the
distinction of Save and Exit and Mark Data as finished. I'm guess if I
don't click Mark data as finished then I can come back and edit it later?
yup and there are a couple of reasons why we have this. first, users
wanted away to distinguish between the two. second, it allows us to
automatically send forms that are complete in the background. third,
marking as finished also lets us know that we have to validate all the
data (not just the current question) before letting the user finish.
this might have to change as when we implement autosave. we'll see.
Then I send the data up to my side but was confused because it was still on
my phone (my intuition was that this was suppose to be a move not a copy.)
This caused some confusion when I started a new round of data entry and then
found that old stuff laying around.
we don't delete files programmatically on send -- we just mark them as
sent. until we have a protocol where we can verify that the data is
safely on the server, i don't think we will ever delete automatically.
the sdcard has tons of room and the data people collect tends to be
too important to accidentally delete. this is something that might be
a preference in the future. as always, if you want it, file a feature
request.
I put some constraints on data but usually I was getting "Sorry this
response is invalid" but didn't tell me why. I'm still not sure as I told
it to limit the length to three characters but it seems to reject any number
of characters. (I'll go back and re look at my form to see if I
misinterpreted something.)
you (or we) might have a bug in the constraint -- can't tell without
looking at the form. if it's a form you can share, use
http://dpaste.com and send me (or the list a link). constraint
messages are a feature that is in odk, but we don't expose in build
(pretty sure it's not in xls2xforms either). if folks want this,
please file a feature request or use purcforms...
So when I viewed the on-line data I was surprised to see that the time stamp
was when the data was submitted not when it was entered. For my application
I will not likely be able to upload in real time but up to hours after the
fact. Part of the data I'm tracking is time of day to the second. Is this
possible?
aggregate automatically stores submission date, but forms can
timestamp the start and end of the form. the build ui is designed for
simple use cases, so we (and the other form designers) don't currently
include that functionality. if you think this is an important feature,
we can probably include it by default in build. please file a feature
request and we'll add it to the list of todos.
OK getting a head of my headlights here but is there a way to included
hidden tags? I need to be able to sort data based on device or data entry
staff.
yup. just like timestamps, imei (device id) and imsi (sim serial) can
be included. it falls into the same category as start and end time
stamps. you can see an example of it's use in the sample widgets form
at http://code.google.com/p/opendatakit/source/browse/Widgets.xml?repo=forms
might be a good idea for you to read through
https://bitbucket.org/javarosa/javarosa/wiki/buildxforms and
https://bitbucket.org/javarosa/javarosa/wiki/xform if you want to find
out some of the hidden functionality.
http://code.google.com/p/opendatakit/source/browse?repo=forms also has
lots of sample forms.
Is it possible to have the form control the look and feel of the client? For
example in my application I would like an instance of Collect to only run
this form. So it wouldn't have to got to so many screens before actually
starting to enter data. Also it would be nice if the form could embed the
message to Collect to tell it to "Move" rather than "Copy" when sending so
that the data is automatically removed when it was uploaded. (Oh and have
the ability to 'mark data as finished' default to selected form controlled
as well.)
while xforms can include look/feel functionality, odk (and most of the
javarosa tools) were designed to ignore most appearance attributes. we
will likely be integrating some in the future to control the feel of
widgets, but the sorts of changes you desire will not be supported.
fortunately, odk is an open source project so if you'd like to remove
some of the screens, or change the mark data as finished, or delete
data on send, no one will stop you. most of these decisions are made
to ensure that 90% of our users are happy. we make it really easy to
change this stuff in the code and in the future we might add some
preferences. that said, i try to stay away from preferences because
they also tend to be more confusing in the long run.
anyway. hope that helps.
