search

farmOS / farmOS-map

farmOS-map is an OpenLayers wrapper library designed for agricultural mapping needs. It can be used in any project that has similar requirements.
https://farmOS.github.io/farmOS-map
MIT License
35 stars 21 forks source link

FarmOS mapping updates #170

Closed gbathree closed 1 year ago

gbathree commented 2 years ago

Funding through OpenCollective here: https://opencollective.com/our-sci/contribute/farmos-map-improvements-42743

FarmOS Mapping library, current maintainer is Morgan, (source here --> https://github.com/farmOS/farmOS-map) is used by SurveyStack as well as core FarmOS itself. It has many useful ag-specific functions, and this project is to contribute more specifically around several projects with common needs.

The full discussion about this occurred here (just FYI for background): https://github.com/farmOS/farmOS-map/issues/161.

Based on initial discussions, he ballpark overall cost would be $7200 which includes some community organizing to spec out the actual work.

Initial scoping - mostly Greg

  1. Complete scoping w/ community (5 hrs, I can help organize this if needed also)
  2. UI/UX drawings (7 hrs, I can help with this also if needed)
  3. Community feedback, update drawings (5hrs, I can help with this also if needed)
  4. Integration of new mapping library features into SurveyStack (15 hours)

Once initial scoping is complete, we will provide better specifications for the below work.

Development - mostly Morgan

symbioquine commented 2 years ago

Just to clarify, I (Morgan) am one of the maintainers of farmOS-map.

Also to set expectations, part of this work will be exploring which of these features make sense as part of the core farmOS-map library - as opposed to being implemented in outside codebases (e.g. farmOS contrib modules) that integrate with the farmOS-map library.

We will probably want a tracking issue that lives elsewhere depending what that exploration yields, but I'm happy for this to live here for now... (Closing #161 in favor of this)

gbathree commented 2 years ago

Pre-work

Pre-email

Meeting 1

(morgan) In-between work - ~1.5 weeks

-------- Recheck our Completed Work date ---------

Meeting 2

Programming

Completed Work (in production on SurveyStack)

gbathree commented 1 year ago

Wanted to comment on the latest release (sorry pretty late) -->

Miro board here:

https://miro.com/app/board/uXjVOop-npg=/?moveToWidget=3458764532325934932&cot=14

Hopefully these are just mostly UI / UX changes. I'd be curious to get others feedback, but generally I feel that the process needs to be really explicit, obvious, and built for mobile (so big buttons, text you can see outside, etc.).

This is a simple mockup but there's more icons that are needed. Also obviously didn't use material design or whatever, so standard buttons etc. should be used.

@symbioquine what do you think?

mstenta commented 1 year ago

@gbathree can you paste a screenshot of the miro you're referring to here for archival purposes?

symbioquine commented 1 year ago

Wanted to comment on the latest release (sorry pretty late)

@gbathree No problem, this has been a bit "back-burnered" for me since I didn't get much feedback regarding the initial prototype/video, but I'm excited to get moving on this again!

Hopefully these are just mostly UI / UX changes. I'd be curious to get others feedback, but generally I feel that the process needs to be really explicit, obvious, and built for mobile (so big buttons, text you can see outside, etc.).

image

image

Yeah, I like what you've done there!

In my initial prototype I kept the icons small-ish and hidden until the user clicks the geolocate button because that provided an easy way to avoid wasting screen real estate in scenarios where "location-based drawing" doesn't make sense.

symbioquine commented 1 year ago

In my initial prototype I kept the icons small-ish and hidden until the user clicks the geolocate button because that provided an easy way to avoid wasting screen real estate in scenarios where "location-based drawing" doesn't make sense.

The screen real estate problem goes away somewhat if the user has "opted in" to a specific "location-based drawing" workflow, but I'd be cautious of adding a button to the list of shape types since it won't be relevant to many users. (Who are drawing from desktops or not physically near the geometries they're drawing.)

The other concern I have with adding the button to the list of shape types is that it would be a bit inconsistent. Each of the 4 existing shape types work the same way - the user taps the button, then taps the map to place points that are part of the selected shape type. In contrast, the proposed button would start a different workflow that behaves differently and potentially lets them draw any of the other shape types.

That's why I put the new buttons in my initial prototype in a separate column to try and make it clearer that they provide functionality "on a different UX axis" (if you will) in terms of modifying the behavior of the existing drawing tooling.

symbioquine commented 1 year ago

As a user, my thought is "I want to trace the field"

... So the initial action I take (button I press) should match that statement as much as possible. The 'find my location' button isn't a bad start, a user wouldn't know when they click on it that that option would be provided.

I agree there's probably a way to make it less hidden (more intuitive) than in my initial prototype.

For farmOS-map as a whole, I think there's a tradeoff between the overall UX and optimizing each feature to allow its use to be more intuitive rather than acquired behavior.

In other words, if we know the user wants to "trace a field" then we don't even need to show them the button - we just drop them straight into that workflow. However, stepping back a layer where we don't know what they want to do, there's a risk in making the top-level buttons too specific also because it may not scale.

There's already 14 buttons on the screen with the existing edit tooling enabled. How many can we add before the cognitive cost of scanning them is worse than the cost of learning that you need to click "geolocate" before you can do "location based drawing"?

gbathree commented 1 year ago

I totally agree there's a lot of buttons already... though actually reading your response makes me realize I'm making the assumption that the website / service which is using the FarmOS Map library is probably already customizing to their needs.

For example, we remove some of the existing buttons to make it slimmer in SurveyStack (see below). So in our case, this only show the things we want to show, and we allow the survey creator to turn on or off the buttons they don't want.

image

We let people turn them on and off in the survey builder (below):

image

It's really rare when you want to give someone a 'do whatever you want on the map' kind of experience. Usually you know if they should be drawing fields, identifying points, or making lines - and it's almost never all 3 at once and giving them more options just causes more errors.

So I think we need to factor in the FarmOS Map developer / service as another decision-maker here. What we're really doing is giving them a range of tools to use for their situation, and we understand they probably won't use them all and that's the intended behavior.

We can also just send out some side by side comparisons to folks on our team and ned and anyone else and get feedback if we want some user testing on this.

symbioquine commented 1 year ago

It's really rare when you want to give someone a 'do whatever you want on the map' kind of experience. Usually you know if they should be drawing fields, identifying points, or making lines - and it's almost never all 3 at once and giving them more options just causes more errors.

That is the default farmOS UX though.

So I think we need to factor in the FarmOS Map developer / service as another decision-maker here. What we're really doing is giving them a range of tools to use for their situation, and we understand they probably won't use them all and that's the intended behavior.

I think that makes sense. However, I think it also highlights a key factor in deciding what belongs in farmOS-map itself vs in a separately owned/maintained library that builds on top of farmOS-map.

If these features are ones which potentially benefit everybody who uses farmOS/farmOS-map out of the box, I feel better about increasing the size of the library and its maintenance footprint. OTOH, if we're adding something that is only useful once the map integration has been customized and feels fairly incompatible with the default farmOS-map UX in farmOS, it probably should be out in its own library. (I'm still available to help build the later, but my preference would be for the former since it helps everybody.)

gbathree commented 1 year ago

Well, that's fair - it is the default in FarmOS in the locations it's used today... but like... in FieldKit that wouldn't be the default right? Also, aren't there areas in farmOS where the map is going to be a trimmed version?

An example would be the work that Paul is doing for Regen Digital, for example creating a project boundary. A project boundary needs to be an area, not points or other things... so I would assume Paul's implementation of a project boundary creation tool would allow only areas.

The same would be true for selection of points for soil sampling. I think there will be an increasing number of times when you'll want to... I suppose at a minimum... validate that the saved map values are consistent with what you need (point samples for a soil sample, for example).

I don't know, I'd be curious to get other thoughts on this from @paul121 or @mstenta ... do you think the full blown farmOS Map is going to be the standard implementation most of the time? Is adding to it detrimental to it's current use, or is trimming it down for use ok?

I think if we don't add another button, we'd need to find another solution that's consistent with ensuring a user can successfully use this without having to read the docs or watch tutorials.

mstenta commented 1 year ago

I'd be curious to get other thoughts on this from @paul121 or @mstenta ... do you think the full blown farmOS Map is going to be the standard implementation most of the time? Is adding to it detrimental to it's current use, or is trimming it down for use ok?

I think the point @symbioquine is making is that right now farmOS itself uses the "full-blown" farmOS map (with any default buttons/behaviors it ships with) in most places in the farmOS UI. And so we have to consider each new addition that will add buttons/UI to that "default" case.

It would be great if each of those instances could be "trimmed down" to fit the use-case at hand, but that's the catch: the basic farmOS UI (for editing logs, assets, etc) is very general, and can't know in advance what the use-case is.

eg: Someone is editing a log. Do they want to draw points? Lines? Polygons? Do they need geolocation to find themselves on the map? Do they need a snapping grid? Maybe they need all of these at different points in their record keeping. Right now we just turn them all on... but as more and more of these (great!) features get added, we are potentially adding more buttons, more visual and cognitive overhead, and the tradeoff of UX starts to shift.

Higher-level modules or apps that use farmOS-map can tailor it, but we still have to consider what to include in the "default" farmOS-map that gets used in farmOS UIs.

We've discussed possible solutions/next-steps to address this. For example, moving more things into the sidebar. Or adding settings to the sidebar that lets the user toggle on/off buttons (and remember that so it is saved for next time). We're just not there yet... so we still need to consider each addition and how it will add to the default UX.

There's also library filesize to consider, as @symbioquine said. JS-based apps can "tree shake" to only use the bits of code they want. But farmOS itself doesn't have that luxury, since it needs to load the "packaged" library (built by Webpack) on any page that uses a map via a standard <script> tag. @symbioquine has done some great work using Webpack's "chunking" mechanisms to ease some of this, but it's still always a consideration nevertheless.

I think we need to factor in the FarmOS Map developer / service as another decision-maker here.

Fully agree with this too! I'm in favor of making as much configurable as possible, so app developers who are using farmOS-map can decide which bits to turn on/off.

So in summary: we've got lots of work to do to make this library even better / more reusable / more efficient! :-D

gbathree commented 1 year ago

Just checking in on this @symbioquine to see where we're at. I'd like to make sure to deliver for Regen Network since they are paying for it (though haven't yet paid, but assuming they will) - if there are discussions to have to make decisions which should include Mike or others let's have them. Or perhaps we're on our way and there's no discussion needed (I apologize sometimes I forgot where things are at, so if I should already know that's my bad) :) Anyway - just checking in!

mstenta commented 1 year ago

@gbathree FYI the button SVG improvements PR (#179) has been merged, and was included in the v2.0.8 release of farmOS-map, which was then included in the recent 2.0.0-beta7 release of farmOS. I still need to push this release out to Farmier-hosted instances. GOAT and Covid have delayed that, but hope to soon!

symbioquine commented 1 year ago

I've been rereading this issue and wondering if we're running into an impasse because we're not thinking big enough...

The problem that @gbathree is highlighting about the geolocation drawing features' UX also applies to the rest of the UI not really being very usable on mobile. Some of the issues:

I'm wondering if we should consider a different UX for devices without a fine precision pointing device. That could maybe be detected using something like this:

!window.matchMedia("(any-pointer:fine)").matches;

Then we could present a simpler "workflow driven" UX - the workflow Greg mocked up above with the big blue buttons could then be a subset of (and consistent with) that overall UX.

jgaehring commented 1 year ago

Hey there, sorry for my delay with this (brief illness plus Field Kit stuff sidetracked me for about 1.5 wks), but here's my timetable and estimates for the specific features we discussed in our last call around that time:

Feature Set Time Est. USD Est. Delivery Date
Tracing & Pointing 24 - 30 hrs $1440 - $1800 Feb 24, 2023
Import/Export KML 6 - 9 hrs $360 - $540 Mar 3, 2023
Tabular View n/a n/a n/a

Based on our discussion of the "Tracing & Pointing" feature, and the desire to use a more complex RECORD / PAUSE / STOP pattern in the design (à la the typical phone camera UI for recording video), I've increased the estimate there a bit. And since, I believe the specific requirements for the "Tabular View" feature still need to be fleshed out a little more and scoped accordingly, I'm holding off on providing any estimates on that just yet. I suspect I'll have a better sense of the work that will entail once I've at least started work on the other features.

gbathree commented 1 year ago

That looks great Jamie - we'll scope tabular view once we're done with the rest. I'm sure we'll have some review and revisions too, so I'll assume it'll be a bit more than the quote here to really get a complete "1.0" version out.

I'm really excited to have this moving along. Also appreciate the work you've done with Octavio and getting some of those elements in farmos js that help us standardize the work we're doing in the coffee shop etc.

mstenta commented 1 year ago

Can we close this issue and move these broader discussions / project management details somewhere else? Perhaps the Our Sci GitLab or the farmOS community forum? Looking back most of this discussion would have been better suited to a forum topic IMO.

Ideally this issue queue is reserved for specific/targeted changes with clear criteria to close each issue. The forum is better for open-ended brainstorming, and then specific tasks can be spun off from there. It's also easier to review/understand smaller incremental changes to a project like this, which has many users/stakeholders already.

I imagine there will be a number of issues and pull requests that spin off of this work. Excited to see the details! :-)