South Bay Streets (SBS) – User’s Guide for AppTasks
© 2025 McQuillin & Associates Inc. -- Company Confidential
Guide Ver 0.7 – 2025-05-06 – For South Bay Streets Ver 0.8 – R. McQuillin
1. NOTE: ROUGH DRAFT – PARTIALLY COMPLETED – WORK IN PROGRESS
2. NOTE: This document is COMPANY CONFIDENTIAL with limited distribution. It has been provided to you for early review. Please do not forward, copy, or otherwise distribute it without prior authorization.
3. WARNING: This guide may be updated often. Avoid using outdated copies. Please note the version number above. A version history is shown at the end of this guide.
Contents
1.1 Who is this for (the Audience)?
3 Reporting Requests versus Bugs.
5.1 (Member) Review Your Requests
6.1 What is South Bay Streets (Streets) and Why Use It?
6.3 Use This Guide alongside the Application
7 Terms and Abbreviations (Application-Specific)
9 Appendix: Use Case Template (Author)
|
Version |
Date |
Primary Author |
Change Summary |
|
0.8 |
2025-05-06 |
R.McQuillin |
Original |
|
|
|
|
|
|
|
|
|
|
It’s for anyone who uses the Streets app and wants to help make it better. Or, even if you’re not using the app yet, and you have a request, we want to hear it.
There are three different ‘levels’ of users:
1. Guests. You haven’t even created an account – silly you!
2. Members. You have an account.
3. Insiders. You’re one of our stakeholders OR a support associate, helping to respond to requests and improve the app.
1.
Any guest or user or anyone. Request a change. This can be
anything: a request for a new capability or a bug fix. For now, you’ll need
to create an account to make requests or report bugs.
The rest of these are for insiders of some type:
1. Stakeholder. Identify an issue, submit a “wish”, etc.
2. Team Lead. Assign a task. For example, build a map, write some content, do customer outreach, etc.
3. Tester. Identify and record an issue (bug).
4. Developer. Log internal ToDo’s. Things that remain to be done on the app.
Let’s cover these three in order:
You’ll see this choice on all request forms, so let’s explain it now. There are two major types of submissions: Request and Bug Reports.
With Requests, we just want to know what you want. Of course, the more you can say, the better, including:
1. What you want
2. What drives you to want it.
3. How the app will be better with your change. Specifically, if it’s not obvious, what new thing (s) will you be able to do, or what problem(s) you currently have will be resolved.
4. Any background information you can provide: links, references, etc.
But you report this all in one ‘text box’ and say whatever you feel is needed.
Reporting Bugs is different, and there’s a time-tested format:
1. Where in the app were you, and what action did you take?
2. What were you expecting to happen?
Uh-OH!
3. What actually happened?
Here’s a quick example:
1. I was on the Redondo Beach maps page. I clicked on the ARTesia Boulevard map.
2. I expected to see the map of ARTesia Blvd.
3. It took me to a list of maps in San Francisco instead!
Try to use this format if you can. If you can’t, you can’t. But you would be amazed how this lets us zero in on the problem a lot more quickly than hearing that “The system crashed.” 😊
1. From the “The Site” menu, click on Request Change.
2. Select a type: either a Request or a Bug Report.
3. Fill in the required fields.
4. (Optional) Fill in the non-required fields. The more information you can provide, the better and faster a response can be, and it will be more likely to be what you wanted.
We’re always interested in what guests want to see. However, as a member, we may prioritize your request higher, and there are other benefits, described next.
Members submit requests in the same way as guests (above), except you can access the “Request Change” from the Help menu.
Once your change is submitted, you can be done, and thank
you! However, there are some other things you can do. (These are possibly
mainly because we know who you are.)
1. (Comin soon) You can modify your request, attach documents, etc. until we have started working on it, and maybe still even then.
2. (Comin soon) We can contact you for more information if we need it. (You don’t have to answer.)
3. You can track the progress of all your requests.
4. You can be notified when your request has been completed and published.
1. From the Help menu, click on Review Requests. You’ll see the list of requests that you have submitted, including their status.
Insiders submit requests like members,
(This section provides a quick recap. See the SouthBayStreets Introduction for a better introduction.)
(South Bay Streets (“Streets”) is a also web application that you use to create and manage a database of your goals and needs. Those capabilities are covered in the general South Bay Streets User Guide. )
1. The SouthBayStreets Introduction
This guide has some screen shots, but not for all topics. If you can, we recommend that you open this guide on-screen next to the Streets screen(s) you want to work with and follow the instructions step-by-step using the live screen. Or you could print out the guide.
NOTE: See also Terms and Abbreviations (General) in the Streets Introduction document. Those terms are also needed to understand this document. This is a list of additional terms for actually interacting with the application.
|
Term |
Meaning |
|
Actor |
|
|
Use Case |
A Use Case is a “How To”: It is a task performed by an actor (a user in a role) using the application to complete an operation. |
|
Page |
|
These are the five main types of requests that can be made and the ‘actors’ who make them:
1.
(This document author may use this template to create new Use Case topics.
· Trigger.
· Preconditions.
· Procedure.
· Results.
· WARNING(S): Things to be cautious of when performing this task.
NOTE(S): Other important aspects or implications of this task.
The Overall AppTask Workflow
(THIS DOCUMENT IS STILL IN EARLY DEVELOPMENT)