MVP Wireframes/Mock-ups

Question

MVP Wireframes/Mock-ups

chrismgonzalez opened this issue 5 years ago · 63 comments

Answer 1 · 2019-10-21T04:13:22.000Z

@chrismgonzalez I'll handle some of those :)

Answer 2 · 2019-10-21T20:16:54.000Z

Pinging @ryandudek @louistsaitszho @aeganaden @booleanhunter since they offered design assistance in #11

Answer 3 · 2019-10-21T20:25:42.000Z

I can try coming up with some landing page variations over the weekend.

Answer 4 · 2019-10-22T11:47:54.000Z

Design flow of an organization's deployed instance

I want to keep things clear so that we all don't end up creating wrong wireframes and to ensure we are on the same page :). So below I'm proposing a detailed design flow which is targetting MVP. If I go wrong somewhere please correct me @chrismgonzalez, @allella. After finalizing this, we'll start building components on the client-side. Let's start.

Note for maintainers: Please don't edit this comment. Suggest improvements by commenting to this thread. We'll create a final design flow after incorporating all the suggestions. Thank you :)

In the below design flow, header, nav, main refers to html elements.

Landing page & navigatable pages design flow

By landing page, we mean the page users will see when they visit an organization's deployed instance, e.g. https://chapter.womenwhocode.org not https://chapter.io. For MVP, the chapter project won't host its own website. README.md will act as our landing page and API docs will reside on the Wiki of the repo. What do you think about this @chrismgonzalez?

Navigation bar design flow

logo of organization along with: search box, home, chapters, events, sign in/register. The nav should remain same across all the pages. Here's the design flow of nav items:
- On landing page the search box will be on the header with details of organization. User can input a city, state, or country name to search for events. If I search for NYC then I'll see the chapters in NYC and all the upcoming events in NYC in the results page.
  
  When we go to any other page the search box will transition to nav. If we can't find any events & chapters for the entered location then it should show the 10 upcoming events using the api call /events in results not found page.
- clicking on home & logo directs to landing page.
- clicking on chapters directs to a page where all the chapters of the organization will be listed
  along with its details. Clicking on a chapter will take me to the chapter's page where the chapter details will be shown in header and all the upcoming events of that chapter will be listed with its details in main and there will be a button to rsvp in each event card.
- clicking on events directs to a page where all the upcoming events will be listed in chronological manner. For e.g. events will be in order 23 oct, 27 oct and then 3 nov.
- sign in and register (it's 100% free) will be in 2 different buttons. Sign in takes to a minimal sign in page, a centered div with two fields - email & password, a button to sign in, forgot password and a register link if not yet registered. An email will be sent to the entered email address with an OTP.
  
  After entering OTP, the next page will depend on the origin of api call. Suppose if sigin was called from /chapters/chapterid/events/45896 to rsvp to event 45896 then it should take us back to that event and show "you are going to this event! We have sent you an email with the details of events and its organizers" message. If it was called from homepage then it should take us back to homepage with a success message. I hope things are clear. We need minimum friction here.

Header content design flow:

after nav we'll have a description of organization and the search box under a parent div. Going to any other page will transition search box to nav. We have already discussed the flow of searching earlier so I'm skipping it.

Main content design flow:

after header we'll show the upcoming events of that organization in chronological order. In the event card there'll be venue, timing, date, description of the event and remaining seats. There should be a button to rsvp to it.
- Clicking on the rsvp button will trigger the signin flow if not signed in. If we have signed in or after completing the sigin process we'll see a message stating "you are going to this event! We have sent you an email with the details of events and its organizers".

Organizer and administrator design flow

In the case of organizer & administrator. We'll show a manage nav above the main site navigation inspired by world's largest CMS - WordPress. We'll show something like:

Click on image to see in high resolution.

We'll not alter anyother part of app for organizers or administrators. We can show the admin panel nav items in a vertical navbar, something like:

Clicking on chapters will show all the chapters on side of nav, we can add or edit chapters. Clicking on events, will list all events, event organizer or admin can make edits and create a new event. They can also email participants from this view. Settings might be useful for customization of the app.

In short our admin panel should be in lines of:

This is a very rough idea of what's going on my mind right now. We can evolve our design upon this. Also now we can start drawing wireframes by following this design flow.

I encourage you to suggest improvements to this. Your suggestions will help our team in delivering an amazing UX to you :)

@QuincyLarson your thoughts on this?

cc @kognise @francocorreasosa @Zeko369 @nik-john @timmyichen @allella @chrismgonzalez.

Answer 5 · 2019-10-23T03:38:10.000Z

Should we be taking a mobile first approach to our designs? I believe we should.

Answer 6 · 2019-10-23T03:41:19.000Z

@finisher1017 I have that in mind too.
Maybe that or just create another path for mobile developers to think about the design and development stack.

Answer 7 · 2019-10-23T03:43:04.000Z

@vkWeb that's an impressive start, and amount of stuff to think about.

First question is who's going to be creating the mockups? I want to confirm the folks doing the work are already in the conversation since their input and process will matter more than mine.

Also, I'm neither a designer or experience in the ways of Kanban. I suspect there's a pattern for using the user stories to generate mockups, but perhaps that's a later step.

I can see the need for discussing elements which are universal to the UX, like header, footer, sidebars, so what you shared above hits a lot of that concern and is a good base regardless of the how we organize it.

Answer 8 · 2019-10-23T03:49:24.000Z

I think at the very least the MVP should be a browser based app that's optimized for mobile devices. I'm planning on starting work on some wireframes tomorrow that I'll share when I feel like I have something ready to be critiqued.

Answer 9 · 2019-10-23T03:55:59.000Z

I set up the Figma board here: https://www.figma.com/file/EDhlnW52lIYZmiarrCaopx/freeCodeCamp-Chapter-Project?node-id=14%3A3

I don't want everyone to have edit access, just the designers. Once you click the link, everyone's names will show up and then I will give access to those who are designers.

Answer 10 · 2019-10-23T04:05:34.000Z

I have a mockup about halfway finished on XD. Once I'm done, feel free to pick it apart!

Answer 11 · 2019-10-23T04:06:12.000Z

I'm helping develop the iOS app as well!

Answer 12 · 2019-10-23T04:11:32.000Z

Oh that's a good start.

Answer 13 · 2019-10-23T05:09:24.000Z

I think at the very least the MVP should be a browser based

I disagree here. It's important we make mobile first deigns because the app is going to be consumed heavily on mobile form factors. Designing mobile first helps us prioritize real estate and make mobile first development possible. That way we develop up via. progressive enhancement. Otherwise this becomes afterthought. I've seen many a project go down because we took that approach. Heavily recommend mobile first designs.
Browser should be second priority

Answer 14 · 2019-10-23T06:54:21.000Z

What I mean by mobile first is considering how the layout will appear on a mobile device, regardless of whether its browser based or a native mobile app, the layout should be similar in either case. Having a mobile responsive web based MVP utilizing CSS media queries should give us a solid base for collaborating on any potential native options, especially considering that any modern web based apps should be optimized for mobile anyway, at least IMO.

Answer 15 · 2019-10-23T08:44:23.000Z

Ah I see - if it is mobile-web vs native, then I agree. That is absolutely mobile-first design. I misconstrued what you said - in fact, I see that you suggested mobile first in your comment above 😄 I guess it is more for the other designers out there I guess

Answer 16 · 2019-10-23T18:43:53.000Z

Are making two individual apps for both user and organizers? Or are we going to allow everyone to create their own events directly from one app?

Answer 17 · 2019-10-23T19:55:12.000Z

Are we using any existing CSS Framework like Bootstrap? And build on top of it?

Answer 18 · 2019-10-23T20:01:16.000Z

@nabilahsan #34 and #121 talk about bootstrap-styled and other bootstrap variants and alternatives. I haven't seen a consensus on that but @vaibhavsingh97 @nik-john @francocorreasosa @vkWeb and others were part of those conversations, so pinging them for thoughts.

Answer 19 · 2019-10-23T20:22:41.000Z

Are we using any existing CSS Framework like Bootstrap? And build on top of it?

@nabilahsan I would highly discourage using any CSS framework. I think with flexbox, grid, css variables at hand, css frameworks aren't that necessary.

Answer 20 · 2019-10-23T20:28:41.000Z

What about components like buttons, date pickers, accordions and input fields?

Answer 21 · 2019-10-23T21:09:01.000Z

I can't see any problem with buttons, date pickers and input fields. Implementing accordion is a task I agree with.

We can use <input type= "date"> for date pickers. We don't need to style input fields much for MVP.

btw, where we'll use accordions?

Answer 22 · 2019-10-23T21:14:32.000Z

I was just giving an example. With every design decision we make, we will have to be in communication with the devs to see what's possible and what isn't. So no over the top designs from us. Only what's necessary and functional.

Answer 23 · 2019-10-23T22:40:21.000Z

It's generally a matter of time and effort that drives the decision whether to use UI libs or not. We can always build our components from scratch and make them super slick, but unfortunately that involves a lot of time, and a lot of re-inventing the wheel. A simple component like a datepicker has multiple implementations across browsers. Now, one can say we should then use Normalizer or ResetCss for that. But then again non-primitive components like accordions that we develop will also need to be cross browser compatible - something that CSS reset libs wouldn't be able to help out with. So it's more likely than not that we will end up using some library or the other

Here's my suggestion - while we deliberate on what UI library to use (Material vs Bootstrap vs X), the designs should use standard UI components that don't deviate substantially from convention. If you need a superset to choose from, refer to either https://material-ui.com/ or https://getbootstrap.com/docs/4.3/components/alerts - anything that's there should be doable regardless of the libs we choose eventually

Answer 24 · 2019-10-23T23:39:01.000Z

I would highly discourage using any CSS framework. I think with flexbox, grid, css variables at hand, css frameworks aren't that necessary.

I agree. Also using features supported directly by CSS instead of a framework would save us from having to migrate to newer versions of the framework when breaking changes are introduced in future releases.

Answer 25 · 2019-10-24T00:14:03.000Z

This is an early draft of a mockup I made for the login page viewed from a mobile device. I'm not sure if we're going to include a traditional registration/login or if were strictly using Oauth, but in the interest of keeping things simple for now I just included buttons for Oauth. I'm also working on views for larger screen sizes, but as I previously stated I think its a good idea to focus on mobile first.

Answer 26 · 2019-10-24T00:27:37.000Z

I just noticed in the user stories that a traditional registration/login is intended so I'll work on incorporating that into my other mockups.

Answer 27 · 2019-10-24T05:54:51.000Z

@finisher1017 That's a good start!!

Regarding

using features supported directly by CSS instead of a framework would save us from having to migrate to newer versions of the framework when breaking changes are introduced in future releases.

The issue with using native CSS features like Grid and Flexbox on a public facing app where we have no control over what browser/device the user is going to use is cross browser issues. And support for older browsers. While Flexbox and Grid are both supported on most modern browsers, we need to make sure our app works on the most basic browsers. For example, you can see below that Grid isn't supported on Opera Mini, which happens to be very popular in Bangladesh, Sri Lanka, Ghana, Nigeria etc.

Not to mention inconsistencies in implementation between browsers. Also, almost no UI libs need to be upgraded that often. You can still use Bootstrap 3 on most modern browsers. The benefits far outweigh the cons from my experience. Plus, these libs implement modern CSS in any case - Flexbox is used in Bootstrap 4 internally. Not using some standard lib in large projects just means you spend days on CSS issues other people have already solved - having done that myself for years, I highly recommend not doing that 😄

Answer 28 · 2019-10-24T11:39:52.000Z

I agree with using native CSS3 over a frameworks bulk + additional learning, Flexbox but not Grid. We should set a stopping point on what browser versions we are willing to support that matches FCC's current policy. Digging around for this information, might just ask Quincy.

Answer 29 · 2019-10-24T15:02:41.000Z

We should set a stopping point on what browser versions we are willing to support that matches

Agree. We should have a Browser support spec for sure.

bulk + additional learning

I would argue that if anything, adding a UI lib would only decrease the amount of code we need to write and include because there's more DRY. And simple libs like Bootstrap are already extremely popular among devs and even if it isn't the learning curve is minimal. Vanilla CSS3 also will make debugging and maintenance more time consuming, in addition to development. I'm not saying we should not be using CSS3, just that it should be used to in conjunction with a grid/UI lib

Answer 30 · 2019-10-24T16:04:43.000Z

I'd recommend not going the UI library route for a couple of reasons:

1.) Is decreasing development work the goal here? The freecodecamp community will have more opportunities to contribute if more components need to be made from scratch.

However, if getting something out the door is a higher priority we should only import a library that allows you to do it in parts (over the whole thing) because...

2.) There is no need to import a bloated grid system or other unnecessary parts of a UI library that already come baked in to CSS.

I get the concern about obscure browser support, but there are viable workarounds.

Using the @supports tag and mobile first approach, the remaining ~8% of users can still have a pleasant product experience with a minimal amount of effort on our part.

If we never use these tools, we'll only be holding the internet back because vendors won't update support to meet a lack of demand.

Answer 31 · 2019-10-24T16:14:27.000Z

While we do want opportunities for people to contribute, I feel like a home-grown UI framework is not the place for that due to the overall cohesion required to make for solid design. We can import the basic components we need from a UI library and create the others ourselves.

I'm a bit fan of Semantic UI as its react support is excellent and well documented.

Answer 32 · 2019-10-24T16:16:02.000Z

While we do want opportunities for people to contribute, I feel like a home-grown UI framework is not the place for that due to the overall cohesion required to make for solid design. We can import the basic components we need from a UI library and create the others ourselves.

I agree with this!

Answer 33 · 2019-10-24T17:08:37.000Z

That makes sense. I heard Semantic-UI has a lot of !important tags everywhere, which can lead to customization problems. If that's not the case it's as good as any, (better in the case of names of things).

For clarification my grid recommendation is only for larger layouts/nested components. Flexbox should be used in tandem on smaller parts because life's too short for that level of nested grids.

Answer 34 · 2019-10-24T17:13:40.000Z

Indeed, a quick ctrl+F of the CSS file shows >1800 occurrences of !important so it's a completely fair concern - any other UI lib will likely be fine. 🙃

Agreed on the grid bits.

Answer 35 · 2019-10-24T17:41:14.000Z

styled-components ThemeProvider will out-! important any !importants included ahead of it, so customization shouldn't be an issue 😁😁

Answer 36 · 2019-10-24T19:59:38.000Z

@allella In the interest of documentation, we should define a Browser Support Level Matrix like @ceciliaconsta3 mentioned. For the MVP I personally think it's good enough to support latest - 2 Chrome (desktop, android), Firefox, Safari (Desktop, iOS), IE10+ & Edge but because this is going to be an absolutely public facing app allowing us no control over what Geography, Device or Networks it is being used in, we will need to support pretty much all possible scenarios including Opera Mini and UC Browser. Even if we don't develop for these two, the app should work on them and we should definitely follow Progressive Enhancement

Answer 37 · 2019-10-24T20:53:05.000Z

@nik-john I could see that conversation having a lot of input. How about we make your last comment a new issue and we can ask Quincy and Eric (works on FCC) for their input and go from there?

Answer 38 · 2019-10-24T22:34:45.000Z

@allella #144 Done

Answer 39 · 2019-10-25T02:38:39.000Z

Hi all, I've been pretty busy this week at work and with school. I'm glad this thread took off! Here are my thoughts:

We should be taking a mobile first approach. A high percentage of our users will be viewing the site on their mobile devices.
@nik-john was spot on above about users in countries that may not be on the latest browsers. We should consider our options when it comes to using design patterns that will support browsers like those used in Bangladesh, Nigeria, etc.
I'm not sure it's a great idea to use Bootstrap. Are we wanting to keep this design very minimal? If so, perhaps using a library like Semantic UI would be a good idea.
I like the start that @vkWeb has done above. Good work my friend!

Answer 40 · 2019-10-25T03:21:14.000Z

I would say to share your design @Uptiie here, so everyone can give their suggestion

Answer 41 · 2019-10-25T07:15:14.000Z

Here are my thoughts:

i agree with @chrismgonzalez that we should follow mobile first design.
I am in favour of having our own UI framework made from ground up using either grid/flexbox and giving fallback support to other browsers. I know sometimes debugging is an issue, but it comes with lots of benefits like we have less unused css compared to UI frameworks, easy to make mobile friendly responsive designs, easy to maintain and devlop components on the go, etc. For example: we have dev.to, i found its the fastest website, because they had written everything from scratch. Also, in terms of performance, having our own UI framework will give us flexibility to tweak to get best performance.
To support maximum browser we will use flexbox as it have 94% browser coverage a dn also we can use table to support browser which not supported by flexbox. Thoughts?

Answer 42 · 2019-10-25T15:13:47.000Z

@vaibhavsingh97 if you have additional thoughts on web browser support then please drop them on #144 as we're anticipating that conversation will grow and we'd like to have all related thoughts in one spot.

Answer 43 · 2019-10-27T04:36:49.000Z

I also agree with @chrismgonzalez that we should go mobile-first - certainly for the participant-focused user experiences. Participants will use Chapter a lot on their phones when traveling to and checking into events, so we want the mobile experience to be as good as possible.

I am in favour of having our own UI framework made from ground up using either grid/flexbox and giving fallback support to other browsers.

I think this would be a premature optimization. Instead we can just grab a framework off the shelf and use it for our MVP, then write our own custom, more-optimized UI code later.

Answer 44 · 2019-10-28T05:36:54.000Z

This is a rich discussion, and a lot of people have shared good ideas here.

This issue is now critical path for our MVP. So I'm going to make some executive decisions to move things along.

We just need some simple functional mock-ups of all the user stories that @chrismgonzalez listed above.

We have established that our priority is mobile web.

Let's assume everything from the participant side will be done on a phone, and everything from the organizer and admin side will be done from a desktop. We don't need to fuss with specific dimensions - just use standard dimensions and get some rough mock-ups together.

I agree with @vkWeb that the wordpress look is fine for organizers. Mail for Good uses a similar setup.

And congrats to @finisher1017 for creating the first view. That looks good to me. Could you create layouts for these other user stories with a similar level of detail? Could you work with @vkWeb to build these out this week?

Answer 45 · 2019-10-28T07:48:34.000Z

@QuincyLarson Your decisions will definitely help in maintaining the momentum of this project.

@finisher1017 I have sent you a message on Discord. Let's build the mockups.

Answer 46 · 2019-10-28T14:08:16.000Z

Quincy posted initial guidance on web browser support, so that should provide an initial base for the browser concerns mentioned earlier on this issue.

Answer 47 · 2019-11-14T21:47:08.000Z

Created a working TypeScript Component with the UX idea given by @finisher1017
Any feedback?
The Chapter's name would be read from the API and changes depending on what Chapter the user is viewing.