harvesthub / gardenhub Goto Github PK

How are accounts created?

I think when someone has multiple plots in multiple gardens (generally this would be a GM), there should be an option at the top of the page to filter the view by garden. I think this could just be triggered if someone has plots in more than one garden.

Screenshot for context:

If we want to facilitate messaging between users we need some sort of profile screen for users. It can be as limited or complex as we'd like, possibly with privacy settings.

We are not sure how employees are supposed to be assigned a particular harvest. Is this something managers will do on their own (ie. look at a list of upcoming harvests and manually assign them), or something the app should automatically do?

If the app is automatically assigning harvests to employees, on what grounds does it make that decision? Days and hours the employee is scheduled? Specific gardens they are assigned to? Whoever is closest to the particular harvest (like uber)? Some of these are more complicated than others. We need some insight into how the employee management aspect of this over at GardenHub is going to work to make some decisions.

Could you think about this and get back to us by next weekend if possible?

Thanks!

These buttons should actually do these things.

I think it's important we stick to some sort of code guide. This one is a good example: http://codeguide.co/ For the sake of consistency.

I like how Semantic UI does things and kinda want to make our own code reflect the structure and style of Semantic UI as much as possible. One thing weird is that they do not use multiple word classnames at all. They just use spaces... so there's no issue of underscores vs hyphens. It's not just that they use spaces though, they manage to express all their component names using a single word. See here for what I mean, it's kind of incredible.

So, I think we should at the very least:

• Use single word classnames. Multiple words means multiple styles. Is this possible?
• Organize our LESS files into a hierarchy like Semantic UI does where there are subdirectories for views, elements, behaviors, etc.
• Follow some basic rules as outlined on codeguide.co, unless we choose otherwise.

If time permits perhaps we can fork codeguide.co or develop our own.

They were originally uploaded to /static/images/crop_pics and now are appearing in the root... I imagine the database is saving them there somehow.

- [ ] Update css files to be task based vs user based as previously done

• Styles for everything

Since we're writing the front-end in the django project now, can we create a new staging environment that Jen and Ashley can access? The surge one is is essentially useless now, and they won't be able to run the server like we are. I'd like for them to be able to still follow along with the latest updates on the front-end. Lmk what you think!

I was going back and forth on how to build Semantic UI in this project. I finally got the source files to build but it was taking 13 seconds for each page to load on the devserver since it was compiling the whole library at runtime. I decided to give up and just import the .min.css from the node module. This required me to configure a bunch of staticfile stuff to let it read from that directory.

We could simplify the code a lot if we just use the CDN. I give up. I wanted to avoid letting Google track peoples' activity on this site but I'm willing to take the easy route for now until we finish the project and have time to refine the build tools. Let's just use CDNs for jQuery and Semantic UI.

H3's are now big and they're the default font for Semantic UI.

I think we need to convert them into div's or something and maybe use Saira Extra Condensed. As a sidenote, I noticed we're also using Open Sans Condensed... not sure we need so many fonts, let's try to include no more than 1 additional font to Semantic UI.

We may be able to handle some of the elements a bit differently too, like using ui buttons for the order thing or something.

For example, say we have "plot 3" in "Garden A".

A user schedules a Harvest for October 5 to October 9 on plot 3. Then, a user schedules a Harvest for October 5 to October 9 on plot 3. How do we handle that?

Also, a user schedules a Harvest for October 5 to October 9 on plot 3. then, a user schedules a Harvest for October 6 to October 10 on plot 3. How do we handle that?

Regrettably, not all modern browsers support HTML5 input types yet. See: https://caniuse.com/#feat=forms

In particular, FireFox and Safari don't support the input type="date" so it will display as a regular text field without the calendar dropdown. We'll need to fall back on a javascript library that does this most likely, with mobile support being crucial.

I'm thinking that now that we call the independent contractors "pickers" in the app, it only makes sense to refer to the act of harvesting crops as a "pick." After all, pickers "pick". Why should pickers "harvest"? It's literally in the name.

@marykatefain do you see any issue with the semantics behind this or should we do it?

Also:

1. Harvest is a more complicated word. Sure it provides more context, but it's not intuitive regardless.
2. Pickers will be be literally picking crops with their hands. Harvest suggests there may be tools like sickles or machinery involved. We can represent a "Pick" using closed fist surrounding a stalk (think: food not bombs).
3. Pick is cuter.

In #20 I made some mockups with fields where you can select a garden or plot.

I used a map marker to represent a plot, and a map icon to represent a garden. Maybe we could do something more relevant to the actual data types though.

ex. City Harvest vs Parks and Rec gardens

• Be able to send messages to affiliated gardens?
• Community
• "Affiliations" field on Garden model?

I kinda took the idea from Simple's UI. Here's what Simple's UI looks like.

I think we could take some inspiration from it. Something to keep in mind is that Simple's UI was meant for desktop (using a mouse cursor) while we're designing GH mobile first (meant for thumbs). Having big buttons (as they are) is probably good so it's thumb-sized.

For reference this is what we currently have.

I'm thinking at the very least we can:

1. Remove the dividers, they aren't needed.
2. Use a more plain bg color like white or gray, with the text being purple.
3. Have hover states that invert the item color.
4. Use some slightly rounded corners and a nice drop shadow.
5. Add that little arrow at the top. It makes a big difference. It conveys where the dropdown originated from.

Right now the home screen is basically a "view orders" screen. It just lists the user's orders, sorted ascending by the time it was created. I don't think this is useful enough, nor the first thing a user wants to see.

Particularly, I anticipate a user wanting to see the currently active orders first, perhaps sorted by their start date. Other orders can be obfuscated behind an "order history" button which takes the user to a view with their entire order history.

Perhaps they shouldn't even be formatted as "orders" but instead it should show the current date alongside a list of plots being watched for harvest. I'm not sure exactly how to present this in the most useful way. Maybe it could also show the current weather, info about the last harvest, or some other reassuring data.

I think in general a gardener/manager will view the homescreen of the app for two major reasons:

1. The place/cancel an order
2. Reassurance that everything is going as planned

We can solve the first problem with a big purple button to make a new order. For the second problem, how do we address the users' potential anxieties? What information will soothe them? What information will make them feel empowered by the app?

Some things that would be helpful (not a priority, but just putting it on your radar):

1. Brand colors
2. Logo
3. Brand fonts preferences
4. Images you would like used (ex as background image)

If you don't have any of these picked out- that's okay! We can help you choose them. For example we are currently just running with a Creative Commons pic we found online and fonts we just personally like.

Semantic UI already has a concept of a toggle button, about halfway down: https://semantic-ui.com/elements/button.html

I'm thinking our tapicons should actually just be modified toggleable buttons of some sort? I just want a consistent UX so users can anticipate what's clickable.

1. A new user's email address is added to a Plot or Garden.
2. An invite is dispatched to that user with a URL to activate their account.
3. The user is removed from all Plots and Gardens prior to activating their account.
4. ???

What should happen?

As it stands, it will still allow them to make an account, but the site won't be accessible to them since they can't edit any Garden or Plot.

Directions from Alex:

1. For each crop, create an element. That element will have two children. One child will be a checkbox input whose name attribute is in a format like crop_<cropId>. eg name="crop_4". The second child will be the tappable icon.

2. Use CSS to hide the checkbox. Then, write javascript so that when the icon is tapped, the sibling checkbox of the tapped icon is toggled.

3. Finally, write CSS using the adjacent selector (+) so you can style the thumbnail based on whether the sibling checkbox is on or off.

When the form is submitted, it will submit the checkbox data despite it being invisible on the page.
essentially, use javascript to manipulate invisible checkbox data

For the CSS part, you'll want something like so:

.crop input[type="checkbox"]:checked + .icon { /* styles to show when the crop is selected */ }
yes

https://stackoverflow.com/a/30379525

The long and short of this is: anyone can copy GardenHub's source code and do what they want with it. But can they use the GardenHub name and logo?

I think we should develop a policy about how the GardenHub name and logos are intended to be used.

Here are a few possible options:

• The GardenHub name and logo may only be used by HarvestHub.
• The GardenHub name and logo may only be used in ways that HarvestHub approves.
• The GardenHub name and logo may be used by anyone for any purpose.
• The GardenHub name and logo may be used by anyone in certain specific ways that we define.

I don't have a strong feeling towards any one of these options, but I'd like us to make an informed choice and then declare it in our readme.

GardenHub's copyright

The source code of GardenHub is licensed under the GNU AGPL, version 3 or greater. This means that anyone can copy and use the source code for any purpose (including commercially), verbatim or with modifications, with the restriction that they must share any modifications they make under the same license. I think this is great for a web application. We have nothing to lose and everything to gain from this. It makes us much more excited as developers to work on the project, and we feel an intense personal connection to the work that we might not feel otherwise. It's owned by everyone, and as a consequence it's owned by me too. This gives me the desire to craft it into perfection because I partially own it. Basically, I think we're making a great choice regarding this.

Why trademarks are different

Now, trademarks are a different story. Often copyright and trademarks get wrapped up into the term "intellectual property," but I think that phrase is really misinformative. Copyright and trademark are two totally separate theories, with totally different purposes and philosophical backgrounds.

The source code of the program falls under copyright protection. The name of the project and any logos used fall under trademark protection. The purpose of trademark law is to prevent people from deliberately misinforming the public about the origin of certain products and services. So unlike with copyright, I do see a potential tradeoff here, since it could be risky to let anyone use the GardenHub name willy nilly.

What do we want?

Well, in my mind there are two major components of GardenHub.

1. GardenHub, the software, comprised of computer code, that anyone can use, modify, and redistribute.
2. GardenHub, the project by HarvestHub, a Philadelphia-based business that connects people with community gardens.

If GardenHub were the 1st thing, exclusively, I'd say we should let anyone use the name and logo however they'd like.

But because GardenHub is the 2nd thing in addition to the 1st thing, we might want to restrict how people may use the name and logo.

I'm not really sure which we feel more strongly about in terms of the GardenHub identity. In a previous call, Jen said that the HarvestHub/GardenHub identity may be changing. Any news on that? Is GardenHub just a piece of software or is it an organization? I'd love to hear your thoughts.

1. The input fields should immediately take focus so you don't have to click them. This includes the first one and the second one after it comes into view.
2. On the second screen, here should be a "back" button to take you back to the username screen.
3. Some validation should happen on the first screen. Maybe it could detect that a valid email address was entered.

Under what circumstances should a user receive an email notification? Obvious ones off the top of my head:

• Order confirmation to requester upon creation of a new order
• When a pick occurs on one of your orders
• Email a picker when a new order is placed on a garden they pick
• When you've been invited to manage a garden or plot.

We should start thinking about these and create an email template. Discourse has a nice template that maybe we can snag.

We're using the heroku-python-buildpack which automatically runs collectstatic, but I noticed we always have to run it again manually after each deploy. This may be because I've mounted the static files into the host and am serving them from nginx on the host. The Python buildpack compiles them into /tmp and then copies them over? Not sure what's going on here.

Anyway, for now we can use this:

ssh [email protected] run gardenhub python manage.py collectstatic --noinput

These buttons should do these things eventually. Screenshot for context:

See here: https://stackoverflow.com/a/34586172

I made a mistake on this initially. The "static" dir in the project root should only be generated in production by pulling all static files out of each app used by the project.

• How many lbs of each crop got delivered to drop off point

• Total lb per crop by garden

• Checkout at end of garden to record lbs

• Crop names do not need to be linked to plot crop name, just general

I'd like us to figure out the best way to organize our CSS and JS files.

In the past I've used tools to compile everything into one file to reduce HTTP requests. This is likely preferable. We can do it easily with a scss or less compressor for Django.

See Browser Diet for the rationale behind this: https://browserdiet.com/

I'm not sure how to handle JS without complicating the workflow.

• delete_account
• edit_settings
• my_account
• forgot_password
• record_harvest
• upcoming_harvests
• edit_gardeners
• garden_harvests
• garden_settings

We need to figure out some way to convey this, as well as the implications it has on the employee side of things.

Here's a super rough mockup for how I envision the home screen layout:

The logic is all pretty much there, just need to code this.

I included the ability for a person to be a picker on multiple gardens (as well as multiple pickers per garden) which is why there are two gardens listed. Typically pickers will only see one.

Once at least one Harvest has been submitted for a particular order on the given day ("today"), its plot will grey out and get sorted to the end.

I think we can use the app to facilitate new contractors getting really good at their jobs fast by sharing wisdom with them.

Could show a "tips" box for newly registered contractors, with stuff like:

It's a good idea to check a plot on the first day you receive an order. (1/12).

Swipe to get 2/12. After 12/12 you can dismiss it. Or you can dismiss it by an X in the corner at any time.

As it stands, we don't have a clear description of what the workers do. It seems they're kind of autonomous. Still, there is surely some shared wisdom among them.

Rethink file paths to be simpler, then update views.py

This will require rewriting some of the code, but I think it's worth doing.

This one is fine: http://meyerweb.com/eric/tools/css/reset/

If a user deletes a garden, all plots within the garden will also be deleted. This will effectively force all users out of the app who grow exclusively on plots in that garden, since there is nothing left for them to manage.

I'm wondering if garden managers should be allowed to delete gardens, or if this privilege should be reserved only for admins.

On the "Create Order" view we need a way to be able to dynamically render the relevant crops for each plot as the user selects it in the drop down.

This may require an API.

We don't need a stylesheet for the home screen, just one for the list of orders that appears on it. We can rip everything else out since it's now handled by Semantic UI.

Also, _reset.less can also be removed since that's baked into Semantic UI itself.

I'm actually questioning our UI choices to begin with. Under what condition would someone ever not want to harvest all their crops?

Let's figure that out. If we decide it's needed, let's include a "select all" button or something that lets users choose all their crops instead of tapping them all one by one.

Jen mentioned that we want a way people can contact others through the site, like a "messaging" type thing.

I haven't worked out the details, but this is definitely something we can do with email. Since we require users to register with an email address this makes sense.

The minimum effort would be to just include a button that launches the user's email client with the recipient already populated. Then the app wouldn't need to do anything more.

At most, we could include threaded discussions within the dashboard and add "reply by email" functionality kinda like GitHub does. This is best, but most difficult.

I think we should include the first option and then see if we have time towards the end of the project to implement something more complex.

We need to create a way for anyone with authority over a garden in GH to invite people to manage that garden or any plot within that garden. The invitation may be sent via email, which prompts the user to create an account, then grants them access to that plot or garden.

GH admins can invite anyone to manage any garden or plot. People who manage a garden can invite anyone else to manage that garden as well as anyone else to manage a plot in that garden. People who manage a plot may invite anyone else to manage that plot.

I'm wondering if we need any sort of advanced permissioning on top of this. For instance, if a GM invites another GM to manage a garden, can the second GM remove the first GM?

I'm not sure exactly how this should be done, but there should be a way for us to pull a few pieces of data on an order into the front end. Some of these things I imagine would be done in the view, and some may need to be added to the model itself.

1. Order is Open/Closed (this can be generated from the dates)
2. Order status (OK/ something is wrong)
3. Order progress (possibly generated daily by comparing to reported harvests?)

There is a place in the templates already for each of these things, We just need to figure out the best way to generate the data itself so I can pull it in.

Screenshot for context:

Problem statement: We want to autofill peoples' names in the Plot Edit screen when GM's go to add them to a plot. How do we generate the list of people in a way that respects the user's privacy and ensures that the users are relevant to the GM in some way?

Some example cases that could be problematic:

1. A gardener has a GardenHub account and gardens on a certain plot. That user abandons the plot. Later, they decide to come back. Their name should appear in the GM's list.
2. ???

If a plot has no crops an order cannot be placed.

I'm wondering if we need to rethink how crops work, per #46

Per #46 and #49 I think we really need more information about how crops on plots will change over time and think critically about the best UI and database implementation to achieve that. I consider this a blocker right now.

Right now, crops are actually a property of a Plot. For example, Plot 3 in Spring Garden contains tomatoes, lettuce, and oranges. This data is stored about the Plot in the database.

This system requires the gardener to manually edit the Plot any time a new crop is added or removed from the Plot. They must do this before they try to place an order. This is counter-intuitive and a bad user experience. When someone places an order, they already have in mind which crops they want harvested. I imagine most of the time it will be "all of them." Am I correct?

We chose to do it this way for several reasons but I am now second guessing them. I'm thinking the best way to place an order may be for the user to type the name of each crop or to let them pick "harvest all crops". This allows for flexibility. We can also have an auto-complete feature that makes it easy for them to do this.

• Screen for when a user logs in and has no upcoming harvests
• Submit new harvest screen
• Edit plot screen