I just wanted to make a special announcement that in the next Monthly Community Call (Wed, Jan 8, 2PM EST) we’re planning to discuss the future of the Field Kit UI/UX, specifically the “Edit Log” screen.
This screen in particular has irked me for a while, as it’s got so much going on visually, but with very little overarching structure to organize it. I’ve spoken with some users who have made excellent suggestions on how to streamline the interface and experience. Some of them will be joining the call and I’d like to invite the whole community to take part and provide their feedback.
I see two primary avenues for improvement:
Overhaul the existing “Edit Log” Screen so that it can be read and edited more easily and concisely. The current screen has evolved many times over, and often design best practices have taken a backseat to expediency. I’m in the middle of prototyping a new layout which puts an emphasis on readability, and moves away from the traditional form-like layout. You’re welcome to view the prototype here, which we’ll look at in more detail on the 8th, but of course bear in mind it is still a work in progress.
Create new Field Modules, which will provide an alternative to treating all logs all at once. Instead, each Field Module will allow us to design for a specific user scenario, like taking a scouting observation, or assigning a worker with the task of applying an input to a field on a future date. This will be the direction forward for Field Kit in the future, and I expect the “My Logs/Edit Log” module will become less pivotal to day-to-day use of the app, as more specialized Field Modules take it’s place (though we’ve also discussed the idea of transforming it into a general “Log Manager” module for power users and to help with maintenance and debugging).
I hope folks are able to join; the more the merrier! In the meantime, feel free to provide your impressions/suggestions in this thread and we’ll try address them in the call.
Hey Jamie: Thanks for asking. That prototype Edit screen looks like a significant improvement… But i’m still pretty fuzzy on how this fits into the higher-level UX design you have in mind. Would appreciate if you could clarify.
For example: I am as you know wanting a tool to collect field observations in the most agile possible way -ideally: open the app, push a button, take a picture that’s geocoded to my current location, and save/sync/quit (details to be filled-in later, probably back at my desktop, because i’m up to my elbows in field work right now) Angela meanwhile wants something more like a GTD-for-farmers app, if i’m understanding this right, that gives the field worker a list of Assigned Tasks that is filtered according to the context (i.e. current place/time, i presume) of that worker in the field. In fact i also want what Angela wants, and maybe she also wants to Record Field Observations as i do.
Now: does this imply use of 2 different Field Modules? In fact i don’t know what Field Module means; does that refer to some backend structure in FarmOS/ Drupal, or rather to something that is end-user meaningful, like an icon (i.e. app) on my mobile device, or perhaps a top-level menu selection on my FieldKit home screen?
I’m aware that this is a Development discussion, so please pardon my end-user ignorance, but to whatever extent you can express your vision in non-technical language in terms of end-user experience, that will help me to give more meaningful feedback & input. And again, Jamie: thanks for asking (what too many developers never bother to do!
Yes, that’s correct. One for each user scenario. Separate from the current “My Logs/Edit Log” module, which is the only module at this time.
Sorry, poor communication on my part. This is a concept we have fleshed out pretty well in planning, but might be best to illustrate by example, once we have some other modules ready to deploy, which should be soon. In the meantime, I’m just getting the hang of Figma, so perhaps I’ll create a prototype like I did for “Edit Log” to show some examples of how we might use field modules.
For now thought I should say they’re pretty simple, sort of like micro-apps in their own right, which will all be available in Field Kit from a main dashboard. You could call them plugins or widgets or what have you, just little bundles of UI and functionality, packaged up separately. So they’re mainly a frontend concept, a way to create customized user experiences around a particular workflow. The one key part that does involve the Drupal backend, is that it will be possible for farmOS admins to activate and deactivate certain field modules for their farm, remotely from farmOS’s admin config, or even install custom community developed field modules. In this sense they’re much like any other Drupal module, but the only thing they provide is some pluggable UI for Field Kit, so that’s where users will interact with them primarily. The ultimate goal is to provide greater flexibility and specificity without cluttering the UI with features that aren’t critical to each user. So we could potentially develop field modules that are specific to just one farm and its particular workflow, and that farm could load it in separately, without requiring that every other user of Field Kit also loads that module as well. And if a user finds that the observation field module isn’t useful to them, they can deactivate it, so it doesn’t crowd their dashboard any more. Etc, etc.
Hope that helps. I’ll try to get my ducks in a row so I can present a more coherent user story for the 8th.
I know I am late to the discussion and the call has passed but I really like that mock up you provided. I have a lot of the same feelings about the current edit log UI and that new proto looks to really provide some improvements that I would love to try out.
I do not know if this has been mentioned in other discussions or github issues, or maybe I am a blind fool who can’t see but being able to filter out tasks that are don’t would be really great.
Thanks @applecreekacres! Good idea with the done filter. Along similar lines we discussed in the call today the possibility of removing old logs once they’ve been marked as done:
Feel free to open up a separate issue though, that’s a good alternative and I’d be curious to hear other users’ take on it.
Hey @jgaehring : Quick hat-tip just to say: early experience with new v.0.4.13 of FK is much improved. GeoLocation of observations in field seems to be spot-on, tho i must test it more to be sure… And i really appreciate that Log entries are now listed in rev-chrono order (i.e. most recent at top), instead of the reverse. Thanks for this, mate!
