Hour picker improved

  1. This ties in with the redesign of the Global (forum) side. We designed a floating footer which is always present but has three different sets of buttons to match the area of the site: https://publichappinessmovement.com/t/topic/1766/3?u

The idea being that we highlight the key actions available to users, particularly on a mobile. So gather would be next to their thumb all the time

(Myself and a few others chipped in to pay a company to build it as the ruby team hasn’t been active in waay too long and we needed some progress… but they were very cheap and communication was tough and didn’t work out)

  1. We could do if you can define reasons why it’ll be better for users. The UXers who designed it wanted it broken into stages as a long form makes some users drop off because of the effort required. So the decision was to break it up and make it feel more manageable.

The other thing they said was that full screen was good as it removed all distractions. The UK Government Portal was used as a template to follow (although we only went half way towards that vision which would turn each question into its own page).

  1. I agree that isn’t clear for users. The idea is that users can post an activity (gathering), or post themselves onto the map (using a nearby landmark) so others can message them and invite them to meet for a public happiness gathering. To help users find others nearby and self organise meetings and activities. In the future we’ll build an ‘invite all within 2/5/10/20km’ function to power this up.

In the brighter tomorrow map this is used for ‘post an existing resource you’ve found’ and ‘post something kind you can offer to do’, so users are still posting themselves to the map, but with the theme of ‘here’s something kind I can offer to do to help people who are homeless near me’ (guided by crowd sourced ideas in our Reddit forum)

This is purely my idea, but I think this ‘post yourself onto the map’ should be moved into the users profile section, and we automate a notification which can only be removed by completing the form. Users can set their category as ‘currently unavailable’ if they don’t want to be contacted by others nearby.

  1. This is for choosing category/ies. In my browser I see the title as grey text in the box. Users choose the applicable categories and it changes some options in the form.

  2. I’m afraid I’m not sure. This was designed before we began documenting everything.

a. This is/should already be solved in the codebase actually. It was a task someone completed. Right now the backend is doing something odd and it’s interfering with this change. I think its loading two different branches and squishing them together. We need some more members in @SysAdmin to tidy it up.
b. I’m surprised we missed this. Good spot :slightly_smiling_face:
c. The one in the main menu at the top?
d. If that’s easier for users, sure. Create it as a task for the @ReactMeteor team. The same for (b and e)
e. Awesome :sunglasses:
f. Not sure what’s meant, can you expand this plz?
g. I’ve seen that around a lot. I do like the visual clock version most though. It’s so easy

I great, create a task for it tagged Backlog or Sprint
II groovy, create a task for it tagged Backlog or Sprint
III this has always been overly complex for users. create a task for it tagged Backlog or Sprint :wink:

@Mateo I’ve replied to your excellent work. We should begin pulling them out into their own threads.

4 Likes

Hello here,

Here are my answers to yours :slight_smile:

  1. Ok, but I don’t understand where it will be then, on the bottom of the page on the desktop too? @UXers, don’t you think this may be problematic or hard to find? Could it behave differently on desktop and mobile?
  2. Yes, breaking it into stages makes sense, I was just trying to find some use for this column :smiley:
  3. I think your idea of having it in the profile of the user would be better, it may be hard to find if it’s in the Gather option.
  4. Ok, we’ll have to add the label “Category” then.
  5. Ok, no problem then.

a. Ok
c. The one in the “Select an address field”.
d. I might need an explanation on how to create a task, is there a guide where I can look at that?
f. Oups I didn’t wrote all the message here: is the until field mandatory? Should we hide it by default and add a checkbox? Not very sure about this one.
g. We may need some research here on which is more efficient, but by default I would say users are more used to what they found on other website so we shouldn’t change what is working for them (see Jakob’s law on mental models). Ux team, any recommendations? I also feel this format may look strange for younger users.

For the tasks, same as d., can I create them and assign it to me directly?

That’s it, sorry for taking so much time for answering :slight_smile:

Regards, Mateo

1 Like
  1. it could behave differently. Its on the Z users follow but fairly low priority. Then it follows users while they scroll like a frame they are viewing our site through, so that would make it far more noticeable. The mockup focused on mobile and a trendy footer bar which many sites have begun using. around 83% of our traffic is on a mobile device and our app is just about launching.

Do you think a floating footer that follows the user in every page to show them the main functions in that area of the site wouldn’t be noticeable and convenient on a larger screen?

  1. I understand that. the column looks lovely, but i’m not sure the info in it now is really necessary. Giving users a quick overview does seem to prevent them from actually opening the page where they can interact. The UX team did some small scale testing on this a while ago and came up with the conclusion.
    Our site has the ethos of promoting quality engagement rather than quantity engagement, like most other social sites do. We want users to contribute to planning and building events/projects/resources, and promote collaboration and support, rather than ‘click and move on’.
  1. Agreed

c. ah, i see it. cool
d. there is this: The Switch to Tag-Pages (with examples how to use them effectively)
its lacking in detail. i’ll improve it right now
f. i think this will be easier to work out when we design how to split the forms up. Users/Fixed resources are likely to be indefinite/until someone wants to take them down so hiding that option unless they specifically want it, makes sense. If posting a single gathering/resource, then that option should be visible as it’s likely just one day, or one day each month.
g. i expect that research already exists. we could do it again, or search for it online. i have a strong enough feeling that users will prefer the clock face so that doesn’t bother me too much. If you think its important you are welcome to post it as a task and give it a go.

yes you absolutely can create them and assign them to yourself. no worries about the time, it’s really enjoyable having you here :slight_smile:

Hello guys, sorry but I’ve been busy lately and it’s a little bit hard to find some time to work with this task. Anyway, managed to catch up on what you discussed. Thank you @Mateo and @AndyatFocallocal for your contributions here.

I liked what Mateo did. However, I still wonder if we could make this form easier. Do we really need to collect all this data?

Secondly, don’t you think there is a better way to select an event’s recurrence? Just try to imagine, we have easier ways to set this up, like on google calendar or creating an alarm. Maybe these examples can help us find a better approach to this.

Also, what is the difference between “Intro”, “Event Details” and “Tell us more”? Why don’t we have a single box where I can add all the details?

And lastly, what is the difference between “Creating a Public Happiness Activity” and “Putting Myself on the Map”? Is there a practical difference between these two events?

Yes you’re definitely right, I think we should reduce the amount of information we are asking for, we should define what is mandatory. Only the name ? Name + Time + Address + Information ? I didn’t want to change too much things that are already existing, but if we can move things there, I’ll put only these four fields, so there is only one screen, and the rest can be added in the event’s page.

For the recurrence, yes, the google design is good.

For the “put myself on the map”, we were thinking about moving it out of the Gather option.

What about something simple like that? (needs some work but just for the idea)

The plan from the original UX design with the second description box was to pull in an overview and a how to guide from the approved activity guide.

A few years back when the community was active, but almost all events created (on Facebook) members asked me to help create for them. We surveyed the community and writing the description and advertising their gathering was the most off putting part for them.

So the plan was to automate the description injecting the stock text in the larger description box, but to make it editable so they can change it if they want. That’s partly the reason for the ‘select activity’ drop-down… which does need to be redesigned (into an auto complete probably) when we have 500 approved activities rather than the current 12ish. The other reason is to help users filter on the map.

This is also why we help users recreate the activity on other social media platforms with the splash page after they submit the form.

Keeping with the theme of minimisation I’d suggest the stock text for that activity is hidden, but can be opened and then edited or deleted with a click.

(Users can only post activities approved by the rest of the community. Anyone can suggest a new idea. Once approved for a trial after discussion, then tried and reviewed, it goes into the suggested activities list for others around the world to recreate)

The video links are to encourage users to use our platform to gain views and followers for their kindness based videos, which will be a strong pull for existing groups, communities and industry leaders. It’s a very powerful system for increasing their views, likes and followers. We also wanted to help them promote their other social media profiles.

Essentially this is ‘giving back’ to users by helping them promote their kindness based activities

Thank you @AndyatFocallocal for sharing this with us.

But, how could we make this form simple? Or, is it interesting for the platform to have it simple?

Because it may change the scope of this task, and, I didn’t manage to use the date picker component with the modal form we have right now. So I am still not sure of what to do :frowning:

@Mateo do you think you could update your wireframe, being inspired on Google Calendar’s modal?

What we’re looking for is simplicity, combined with helping guide a user.

Basically when we were running activities regularly, users wanting to create one would always write to me asking for help and that limited how big the community could grow, and when the community was surveyed why they weren’t creating their own activities and just joining in, most found the idea of creating and publicising it overwhelming.

So the design brief for the event form is a bit different to Google’s, we want to help the user create a successful activity.

The plan from the most recent UX wireframe was:

  • to autofill the main description (but allow users to modify it), and have the space above it for the user to write their own message.
  • help users choose a location near by
  • allow users to message an invite to community members nearby
  • help users reach out to others on other platforms
  • encourage them to promote their social media platforms (individually and for existing communities)

If you click ‘global’ then find the ‘UX card’ and click resources, you will find the most recent wireframe

I’m not disagreeing with simplifying it, just that it’s brief is bigger than the Google one in your example. The current design definitely sufferers from us using one form rather than three, one for each purpose

Hello @AndyatFocallocal, I tried to use another react component for the date-picker selector, however, I’m having the same problem with the form. When I try to update the time, it triggers the submit automatically. Please notice that neither preventDefautl() nor stopPropagation() are working here. Unfortunately I’m struggling with this task, and for this reason, I believe that a more experienced developer could work on this one. I am sorry :frowning_face:

1 Like

No worries. This community is great for supporting each other. Just describe your issues and what you’ve tried to fix them about then throw an @ReactMeteor tag in. I’m sure someone will be able to help you find a solution :slightly_smiling_face:

Hey @caike08, do you have a branch up that I could checkout? Haven’t worked on this form in a loooong time but I remember the event propagation was v fiddly; I might be able to help.

Cheers,
Arty

1 Like

Hello, @ArtyS!

Unfortunately, I didn’t commit the changes. I tried to install some different plugins but I had the same results with all of them. I ended up reverting the changes and did another task. But if you feel like trying the plugin and check how it was, here it is: https://github.com/edwardfhsiao/react-picky-date-time

Cheers!

1 Like

Hello,

What could / should I do here? Do you need any design?

Regards

1 Like

You could review the two options posted earlier by Caine. I have a very strong feeling that the clock one is significantly better both from a UX and a UI point of view. Not based on research or learning, just that there’s no scrolling. All the options are just there, I remember when my phone updated and 1st showed me one of those I felt like selecting a time had been solved forever.

1 Like

Had a bit of time today to play around with implementing react-picky-date-time (caike08’s suggested module) and I would actually disagree: I think a clock face is making this more not less complicated, especially where people are using a mouse/trackpad. The module in question is particularly fiddly as you have control over the minute and second hands as well.

I would suggest something much simpler such as:

  • digital time display, showing the selected time rounded to nearest 15min. Starting point/default shows the current time, rounded to nearest 15 min.
  • total of 4 basic buttons that change the selected time, roughly arranged as follows:

[ -1hr ] [ -15m ] [Time Display] [ +15m ] [ +1hr ]

This means people on average need half a dozen clicks to select the desired time, but most importantly no confusing dropdowns or UI to navigate. I think it’s the excess of choice/options to click that is the source of confusion.

Sorry if this has already been proposed - haven’t seen the designs recently.

1 Like

@caike08 @AndyatFocallocal - had some time this weekend so added the above idea for the simplified time picker in the attached PR.

Screenshots are in the PR as well, let me know what you think. Not a perfect solution but I definitely think it’s simpler than having the dropdown to select the time (I’m thinking especially for mobile devices).

1 Like

Thats awesome that you jumped back in to support. Thank you @ArtyS Arty. I waited for other to comment but as no-one did i’ll offer feedback.

the +/- buttons make sense on a mobile device. I see a UX issue though. Some users will want to meet at half past the hour and if that’s a 24hr clock user may have to click that button over 40 times to reach their destination. That seems irritating to me.

We could expand on the idea to have both an hour and minute slot, each with -/+ keys and an am/pm toggle. That would reduce the maximum clicks to 12 which is more reasonable. (the minute slot having 4 options 00, 15, 30, 45 or just 00 and 30)

@UXers what do you think?

Hello, guys! I had added a comment on the PR on GitHub https://github.com/focallocal/fl-maps/pull/1041#issuecomment-596401576. There are some testings failures on it.

@AndyatFocallocal thank you for sharing this concern. I think the 0-15-30-45 approach is interesting!

1 Like