phantomwatson / muncieeventsapp Goto Github PK

Problem

• Login / signup links don't appear in intuitive places when the user is not logged in
• Currently, the user needs to click on "My Profile" in the menu to log in

Suggestion

• If the user is not logged in, show a "Login / Signup" link
  • in the menu that loads the LogInRegister page
  • at the top of the event form, along with text that explains that it's optional but recommended (e.g. "You are currently not logged in and will be submitting this event anonymously. If you log in first, you'll be listed as the event's author and will be able to go back and edit or delete it later if you need to.")
• If the user is logged in, show a "Log off" link in the menu

A library such as React Native Calendar Events should be used to facilitate adding a button that allows the user to copy event information into their device's native calendar.

These are my suggestions for populating the fields of an event object:

• url: URL to access the event on the Muncie Events website
• location: Location name field, with location details field appended if not empty, with address field appended in parentheses if not empty (i.e. "$location $locationDetails ($address)")
• notes and description: The event description

• The tags screen should be limited to only tags associated with upcoming events using the GET /tags/future endpoint
• Each tag should display the number of associated upcoming events, either in a second table column or following the tag name and wrapped in parentheses.
• Each tag, when selected, should send the user to a screen that shows all upcoming events with that tag

My personal preference is that this screen's design be changed from its current layout (a <select> element and submit button) to a list of links that the user can scroll through, but it might be worth considering a variety of layout options.

Goal: Pair up category icons with category names wherever practical.

• When viewing the full details of an event, and at all other times, the category icon should come before the category name, and with roughly an em of padding between them
• On the "edit mailing list settings" page, icons should precede category names
• It should be investigated whether or not there's a practical way to have category icons precede category names on the event form

Note: Depending on whether the app is using fetched or built-in icons, the API may need to be updated to provide category icon URLs.

Currently, to view events on a specific date, users must click Menu > Go to Date > Select Date > (input a date).

It would be less awkward if the second step of the "Go to Date" screen were removed and the menu instead directly opened the date input interface.

The current interface for selecting a date/time doesn't work intuitively. The date, start time, and end time sections of the form don't update after a date or time is selected, but rather a "chosen date and time" section below the three inputs is updated.

I suggest the following

• The selected date are displayed in the "date" section
• The selected times are displayed in their respective "time" sections
• The "clear time" button in the "end time" section only becomes visible when an end time has been selected
• Meridian strings be displayed in this form the same way as they are in other parts of the app (i.e. lowercase and without a space, such as 10:20pm)

• The "Categories" screen should show a list of all categories and the number of upcoming events for each, using the GET /categories endpoint.
• Each category should link to a screen showing a list of all upcoming events matching the selected category.
• Bonus: Display category icons next to category names

When a collection of events is displayed that all share a selected tag, "Tag: {tagName}" should be displayed as the title above the content.

Currently, the series that an event may belong to is not displayed in the application when viewing an event's full details.

To support users navigating from one event in a series to another, the following should be implemented:

• If an event is part of a series, a new section of the event screen should appear between "Where" and "Description" with the header reading "Series", followed by the linked title of the series
• Clicking on the series name should take the user to a clickable list of all events in that series using the GET /event-series/{eventSeriesId} endpoint

A library such as react-native-share should be used to facilitate sharing any event with an external service, such as a social network.

I suggest that the string that gets shared should be "$eventTitle: $eventUrl".

Currently, if any required field isn't filled out, then upon pressing the submit button, the user is told "ERROR: One or more required fields not completed".

Ideally, the following would be implemented:

• Any error messages are displayed in a different style than other messages, such as that used in Bootstrap's .alert-danger class, to make it easier for users to distinguish those messages from other content
• Attention is drawn to the specific field that an error message refers to, such as by highlighting it or displaying an error message directly alongside it
• Upon submitting, the screen is scrolled to the first field that has an accompanying error

In any instance where the user is shown a loading screen, a timeout should be implemented that cancels an unresponsive API request after an appropriate length of time (15 seconds?) and displays the following message:

The Muncie Events server took too long to respond. You may be having problems with your internet connection, or the server might be down at the moment. Please try again.

If a form is being submitted and there is no response from the API, the user should be returned to the form and shown that message above the submit button so they can try submitting it again.

In the case that a page is being loaded that depends on data pulled from the API, rather than a form being submitted, then the user should instead be shown a "try again" button that attempts to load the page again.

Problem

It appears that the user token is not being sent when events are being submitted because when a user logs in, the user token data is only stored in the state of the LogInRegister component. Despite the AddEditEvents component having a state variable for the user token, this never has a value passed to it, and there is no method currently in place for this data to be shared from one component to the other.

Suggestion

• Use Context to elevate user token up to a shared state
• In App.js, I think Context will be modifying the AddEditEvents and LogInRegister variables before they’re passed to the Drawer.Screen components in order to make them consumers of the shared state
• Have LogInRegister component pass updated user token (upon login and logout) to Context
• Have AddEditEvents pull user token from that shared state when initializing its own state

When an event's author is not anonymous, their displayed name should be a clickable link that leads users to a clickable list of all events posted by that author using the GET /user/{userId}/events endpoint.

Note that, like all other API responses that might return a large number of events, these results may be broken up into several pages. Check the first, last, prev, and next properties of the response.links object.

Ideally, pagination is handled by "infinite scrolling", but a "load more" button is an acceptable workaround if infinite scrolling is not (yet) supported.

When the user is logged in, the menu should have a "my events" item that brings up a list of that user's events fetched from the GET /user/{userId}/events API endpoint.

If the API returns no events, the user should be shown the following message:

No published events were found that were posted by your account. If you just submitted a new event, it may still be under review by Muncie Events administrators. Events submitted anonymously (without being logged in) would not show up here.

The "advanced search" screen is currently just where "view events by tag" and "view events by category" live, but both of those features have been proposed to be moved to their own pages.

These are my intentions for the advanced search screen:

• When it is open, a search input field is visible in the body of the screen, and the search field in the header is hidden
• An "upcoming events" versus "past events" toggler is provided
• An "all categories" versus specific categories selector is provided (using the category query string parameter for GET /events/search and GET /events/search/past)
• The user is able to navigate from the search screen to the results screen to an individual event's screen and then back to the results screen and back to the search screen with their input preserved
• The results screen has a title that reflects the user's input, such as Search results for "festival" or Search results for "watercolor" in Art

A method of navigation that some users may expect, but which is not currently supported, is by swiping.

Currently,

• When opening an event, it appears mostly on the screen and slides left until it is fully on the screen.

This sliding animation was part of an unfinished feature that would represent events as being to the right of the home screen and allow users to swipe right to return back to the home screen.

The goal for swipe-navigation would be:

• When an event is selected, any event index page* slides fully off-screen to the left and the event screen then slides fully on-screen to the left
• From an event screen, swiping to the right (or using the device's back button, or using the existing "go back" button) reverses the animations and slides the event and home screens to the right to return the user to the home screen
• Bonus: From the home screen, the user can swipe left to return to the most recently-opened event.

* Event index page: Any page that provides a list of selectable event links.

Examples:

• Home page
• Category page
• Tag page
• Search results page
• Selected date page

Pending development:

• My events
• Events in a selected series
• Events by a selected author
• Events at a selected location

There's a bizarre amount of whitespace at the bottom of the event form after it's been filled out. It seems to only appear after a field has been selected, so this might have something to do with the <KeyboardAvoidingView> component.

The Muncie Events website uses a rich text editor on /events/add for the event description field and supports the following HTML tags being used:

• <p>
• <br>
• <a>
• <strong>
• <b>
• <i>
• <em>
• <u>

The mobile application should also have a rich text editor to duplicate this functionality.

The POST /event API endpoint supports passing an array of multiple dates in order to create a series of multiple events. The mobile application, however, only supports posting an event on a single day.

The application should support a user selecting multiple days when posting an event.