Closed barbeau closed 9 years ago
bbodenmiller
commented
10 years ago I like it. I thought Sound Transit was doing a user study, has anyone heard an update on that?
As a side note this proposal looks very similar to the latest version of The Transit App for iPhone with a sliding drawer, nearby routes, etc.
paulcwatts
commented
10 years ago This looks like a good direction to me, although I think there's some better visual treatment that could happen to make these look better.
I would suggest keeping the "OneBusAway" word at the top rather than a smaller icon. It's a very useful way of getting back to "Home" where it will take you to Map and center the map on your location, so making it easy to hit with your right thumb is very useful.
barbeau
commented
10 years ago @bbodenmiller Thanks for sharing - I hadn't seen the Transit App for iOS, but I did look at the one for Android. Last I heard from Sound Transit the user study was more higher-level, and wouldn't necessarily get down to this level of detail in preferences/features.
@paulcwatts Agreed, I'll replace the OBA icon with the word "OneBusAway". I also agree that this could use polishing and treatment - any specific suggestions? That's something I could definitely use help with.
barbeau
commented
10 years ago I've been looking at some of the implementation details for this, especially for supporting older versions of Android (2.3 Gingerbread, in particular). This involves significant use of Fragments/ActionBar/NavigationDrawer, so we need to have a solid base for those components.
There are two challenges:
I was initially looking at migrating OBA to ActionBarCompat, but lack of good preferences support prevents that from happening. We'd just be replacing one set of deprecated/custom hacks with another.
If we're going to do this right, I'm now leaning towards jumping straight to pure, canonical Android classes (i.e., no support/compat libraries). This will let us work freely with the modern Android components without having to custom shim a bunch of stuff for backwards compatibility that is difficult to maintain, and will be thrown away eventually anyway.
Of course, this would mean the new UI would not be available for Gingerbread 2.3 (API Level 10). If the developer console numbers can be trusted, around 18% of OBA Android users are still on Gingerbread (Gingerbread is around 13.5% of all Android users on Google Play).
My suggestion would be to maintain a legacy branch for bug fixes/tweaks with the old UI, and target API 15 ICS and higher for the UI re-design. Android Studio now uses API 15 as the default minSdkVersion (which runs on over 85% of devices), so this would be in-line with new apps that are being created/released.
@paulcwatts Thoughts on this? We've tried to keep support for Gingerbread in OTP Android, but it results in a half-working version on that platform with some issues that can't really be resolved (there are a lot of one-off errors, and more fragmentation within Gingerbread), and makes development of new features for modern API versions more difficult and time-consuming.
paulcwatts
commented
10 years ago My primary motivation for supporting old versions is social equity. OneBusAway has never been something that was meant only for the folks privileged with the newest, fanciest phones. Even in the pre-mobile-app days, we had tried to keep working the non-app interfaces like mobile web, SMS and phone menus.
I appreciate the desire to keep moving forward, however it would be difficult for me to see abandoning those folks with the older phones. If people would have to reinstall OBA on their Gingerbread phones, would they be able to reinstall this "legacy" version? Could it be in the same app in the Play Store, or would there have to be another app people would have to use?
barbeau
commented
10 years ago @paulcwatts I agree, social equity is important in OBA. tl;dr - I'm not suggesting we abandon Gingerbread entirely - we can continue to push out features/fixes that work well on Gingerbread in a manner that's fairly transparent to users. At a bare minimum, the current version of OBA will continue to be available to download on older platforms.
Long version: Google Play should allow us to continue to publish updates to pre-API 15 devices as a separate APK targeted to just those devices (see Android Docs on "Multiple APKs"). It should actually be transparent to users - no matter your device, find OneBusAway on Google Play, and download the newest version there. Users should only be able to see versions that are compatible with their device (only exception - I believe user's can see screenshots of newer versions - AFAIK you can only show one set of screenshots on Google Play).
The majority of the work falls on us as developers - we would maintain a branch of the project from the current master, and backport fixes/smaller features that work well on Gingerbread back to this branch. Releases for Gingerbread devices would be cut from this branch. The new master branch would be for API 15 and above, and releases for API 15 and up would be cut from this branch. There are strategies for separate version code spaces discussed in the above linked Android doc to ensure that users only get the correct newest APK for them (e.g., 310 for legacy version, and 15310 for API 15+ version).
While this is additional work for us over the current single APK model, in the long run for major changes like this that require newer Android framework components I think its actually less work than trying to maintain a single version that makes compromises in the general framework/app design over all the API levels. And, I think this model may be less of a disservice to Gingerbread users than trying to cram new UI features into a single APK that's pushed down to Gingerbread, and end up with a half-working OBA app, with new features causing more issues than they are solving on Gingerbread.
I'm definitely sensitive to the social equity issue, though - I'll do a little more digging as well and see if there are other options.
paulcwatts
commented
10 years ago In either case it's more work for us developers, either to maintain using custom shims and compatibility libraries or to maintain a separate branch/apk. If we can agree to continue to maintain the old version with bug fixes and potentially minor improvements, I'm comfortable with moving forward without Gingerbread support for the new UI.
I suspect that in 6 months OBA's Gingerbread usage will start getting closer to the 10% range. I could be wrong, though -- GB has been hard for Google to kill :)
barbeau
commented
10 years ago If we can agree to continue to maintain the old version with bug fixes and potentially minor improvements, I'm comfortable with moving forward without Gingerbread support for the new UI.
Sounds good.
I suspect that in 6 months OBA's Gingerbread usage will start getting closer to the 10% range. I could be wrong, though -- GB has been hard for Google to kill :)
That's my suspicion as well :). The other item to keep in mind is that OBA numbers are installed, not necessarily active, users/devices, so the number is likely artificially high (analytics, also on the TODO list, would definitely help here). The console shows another app I maintain still installed on a good number of 1.5 devices. If people are still walking around with Cupcake on an active cell phone, I really want to meet them :).
barbeau
commented
10 years ago Other user UI requests:
1: Have the time color meanings in the app itself, at the bottom or maybe via a quick view button/switch so as not too leave the schedule you're viewing. 2: Have a "satellite" view option on the map. Lastly something I know you might not be able to do is have a bus icon on the map that moves in real-time.
barbeau
commented
10 years ago Looking at some of the past issues, this re-design would address https://github.com/OneBusAway/onebusaway-android/issues/22, https://github.com/OneBusAway/onebusaway-android/issues/108, https://github.com/OneBusAway/onebusaway-android/issues/67, https://github.com/OneBusAway/onebusaway-android/issues/63, https://github.com/OneBusAway/onebusaway-android/issues/39, https://github.com/OneBusAway/onebusaway-android/issues/23, https://github.com/OneBusAway/onebusaway-android/issues/56
barbeau
commented
10 years ago Here are the current RGB values for the dark green being used as a theme color in the OBA iPhone app:
R=90, G=128, B=41
Here's a sample screenshot showing this color on OBA Android ActionBar, bottom sliding panel header, and OBA stop icons:
I prefer this to the brighter green currently being used in OBA Android, and looking back on some of the comments on Google Play it appears other users aren't a huge fan of bright green either. I don't know if this is the right shade, though.
Thoughts?
barbeau
commented
10 years ago Something to make OBA Android more accessible to users with visual impairments based on current use of the iOS app, mentioned in https://github.com/OneBusAway/onebusaway-android/issues/22#issuecomment-53822841:
the nearby stops list on iOS works by listing only the stops currently shown on the map. One way that visually-impaired users locate stops is by using the search mechanism, which is now embedded on our maps view, to map a specific route. They then use the nearby stops button to navigate to the one they want. When the route search goes through, it generally zooms out to show some of the stops along that route that are nearby (I'm not sure of the logic for how many stops it chooses to display or how far to zoom out, but I can look this up).
barbeau
commented
10 years ago From some quick UI testing by @jrharshath, if we keep the color-coded scheme of ETA value for early/ontime/late, we should also color code the "X min delay/early/ontime" text to match the OBA webapp:
I did a pop-study for this with a bunch of people right after our meeting, and found something interesting: on the android interface, the guesses about what the colours might mean were wild and nowhere near correct. However on the web interface, people picked up on the meaning - the colour of the number matched up with the colour of the "on time" or "3 minutes late" text (attached image), and people picked up on that.
paulcwatts
commented
10 years ago Interesting finding!
barbeau
commented
10 years ago Just opened a WIP PR here, complete with an APK download, if anyone wants to try out an initial implementation of the new UI.
paulcwatts
commented
10 years ago I still need to look at this. For better or worse, I joined the ranks of iPhone users last week, so I'm no longer using my Android phone regularly :(
barbeau
commented
10 years ago @paulcwatts Booo! ;)
caitbonnar
commented
10 years ago @paulcwatts welcome to the good side ;)
@barbeau Are you using any special icon for bookmarked stops on the map interface? I ask because we still haven't decided for iPhone. It'd be nice to have some consistency there.
barbeau
commented
10 years ago @caitbonnar Not currently, currently all map icons for stops are the same (see WIP PR for screenshots). I was debating this myself - with the new bottom sliding window in OBA Android its apparent immediately upon tapping on the stop icon whether or not its a favorite (star icon in header is filled if its a favorite, empty if its not - user can toggle star to add/remove favorite stop). The question for Android then is if there is added value in seeing favorites indicated in the map icons, without having to tap on a particular icon, and if so, how to do without without cluttering map. If we decide to add the favorite indicator to the map icons, I'm definitely in favor of using stars to denote favorites.
If you want to play with current icons I'm using for Android, the highest resolution PNG files for bus stops and stars are in this directory. Note that no one else has really signed off on these icons yet - I needed place holders, and put something together quick. The PNGs aren't all perfectly sized yet either for the different directions. The SVG file for the bus stops is here if you want to work off of that.
caitbonnar
commented
10 years ago @barbeau Thanks! You're right, the new interface does make it pretty apparent which stops are in favorites in the sliding drawer.
My thought is mostly for discovering farther stops more efficiently this way. I'm not sure if the bus stop icons disappear as the user zooms out far enough, as they do in iOS (to help with map readability), but you can imagine having the bookmarked stops still appear this way. It isn't necessary that they have a different icon, of course, but it could aid intuitive understanding.
A perhaps more probable use case would be looking for a particular stop in relation to your current position; the differentiated icon in this case could help you know you're getting close to the correct stop.
I'll take a look through the icon directory and see if we can similarly update ours in iOS! We'd like to make a lot of similar UI improvements like you're doing in Android, but we currently lack dev time/resources. :-( Hopefully soon!
barbeau
commented
10 years ago @caitbonnar We load stop icons pretty aggressively in Android - even at the city zoom level we still load up to 200 (IIRC) stop icons. Which 200 load, though, can be somewhat random in extreme zoomed out situations, depending on what the server provides in the stops-for-location REST API response. So, at least based on the current Android implementation, I'm not sure we can guarantee that we load all the user's favorites at higher zoom levels (unless they've been previously captured in a lower zoom level in the same app session). That being said, though, I do think map favorite icons would be most useful in context of looking for another stop/landmark relative to a stop you've used before, which is very doable with the current implementation.
Please keep me posted on your progress on iOS. If we can come to a consensus for how favorite icons are best presented on the map, I should be able to implement this on Android.
paulcwatts
commented
10 years ago Personally I've thought we show icons too aggressively on Android, and it might be a better user experience to show fewer at wider zoom levels -- or do some coalescing. However, I was never annoyed by it enough to do the work to fix it :-)
jrharshath
commented
10 years ago It might be interesting to show clusters of stops at a far enough zoom. Or just show routes instead of stops! I'll be doing some tests with prototypes - I'll include that as a test case and let you all know the results.
barbeau
commented
10 years ago @paulcwatts I've thought the same (and I recall @bdferris saying the same), but I don't recall hearing any complaints from users about it (has anyone else?). Conversely, I've heard complaints about iOS not showing bus stops at further out views, so I think I'd err more on the side of showing too many.
@jrharshath I agree that clustering is probably a good solution for city-level zoom - Android actually has a utility library for implementing this too. More user testing would be great!
paulcwatts
commented
10 years ago Yeah, clustering was what I was thinking of. I'm glad to see it is easier now!
barbeau
commented
10 years ago Looking at the colors we're using for OBA Android for arrival times (and related to https://github.com/OneBusAway/onebusaway-iphone/issues/317, in which users in Tampa have reported that the bright green can't be seen in bright sunlight - and looking at iOS, I believe the green that Android uses is even brighter):
I'd like to align the ETA colors across iOS/Android/webapp. Looks like the OBA web app uses the default CSS green: https://github.com/OneBusAway/onebusaway-application-modules/blob/master/onebusaway-webapp/src/main/resources/org/onebusaway/webapp/gwt/where_library/resources/WhereLibrary.css#L16
According to this, the hex value for this is #008000. Unfortunately, this green is the same color green we have been using on Android for schedule arrival times.
@caitbonnar I believe iOS shows schedule times in black, right? OBA webapp does. I just changed the schedule color to black in Android, thinking that I'd then change the on-time color to match the web. Not sure what to do now. Although, I did just add the color-coding for the early/late/on-time text on Android so users can more early determine what the color of ETA means. So, if colors change, it should be easier for users to pick up on the meanings.
Any thoughts, anyone? Strong objections to changing the apps so they match the color-coding on the web?
caitbonnar
commented
10 years ago @barbeau Yes, iOS shows scheduled arrival times are in black. I agree that some cross-platform consistency would be great.
When I did some user testing with the Deaf Blind Service Center while coming up with the colors to use for the high contrast scheme on iPhone, we found a mid-range green color was best for contrast with both the black and white backgrounds. On the web, this is roughly the #336600 value. I tweaked it a little in the iOS app because of the way it was overlaid on the background, but it is around that value. (Our color value for "On Time" is slightly different -- I think it's brighter. I will probably change it to match the darker green color of the search box scope as well because of the brightness issues.)
Edit:
So you don't have to go look it up, #336600 is this color here:
caitbonnar
commented
10 years ago Also, I like changing the deviation text to match the schemes -- I'll get it into iOS as well!
barbeau
commented
10 years ago @caitbonnar Thanks! If there are no objections we can go with that color green on Android also. I'll make the change in my branch, and we can change back if there are objections.
leggett
commented
10 years ago I've been tinkering on the design a little. I'm not happy with it yet but I figured it was worth sharing and getting feedback from those who know this app and it's users far better.
My working assumption is that OBA is for locals, not tourists. It doesn't help you plan a trip or get directions. It simply tells you when the next bus is. Locals will be in a familiar area getting a familiar bus/train (likely the majority of usage) or in an unfamiliar area where they have already determined what bus they will take (someone told them or they looked up directions in another app).
That stated, OBA should make it super easy (ideally no taps) to see the next bus time for my bus. The easiest way for OBA to know what your bus is if the user favorites a route/stop combo. So, ideally this should be very easy as well.
I'm recommending that you drop the tabs. Recents can be exposed if the user taps on the search box. A list of all favorites can be linked to under the menu button (even better, what if that was all that was in the menu with "Settings" and "Help" at the very end).
The map becomes the default manner of navigation. The card at the bottom highlights any favorites in the view and shows the next arrival time. Below that, it shows the routes for the stop closest to the center point of the map (defaults to my location) which should be reflected by highlighting/enlargening the stop icon on the map.
I've dropped the coloring and information like "delayed 3 minutes". I don't think I really need that information but if it is critical, it can be exposed behind tapping on the route.
Tapping the route number makes it a favorite. Tap again to unfavorite. Tap on the route text or arrival number to expand and see future arrivals and options for other stops or directions.
In summary:
All of this needs more time and thinking to make sure it really scales to the full complexity of transit. The graphical elements also need a lot of work.
leggett
commented
10 years ago Oops, forgot showing the approximate location of the next bus on the map. Purely a visual indicator of how close it is.
barbeau
commented
10 years ago Thanks @leggett! I'll dig into this in more detail soon. I like some of the concepts, and I'll do my best to get them into my current iteration.
Could you provide the assets you used to generate the screenshots (including exact colors,etc.)? That would definitely help me replicate some of this in the app.
leggett
commented
10 years ago Green used for icons and app bar: #5db53b Dark font: #4a4a4a Light font: #999
Photoshop file: https://drive.google.com/file/d/0B6RRvrJe3YJaeDNZLWk3c3dkLVk/view
barbeau
commented
10 years ago @leggett Thanks! How about darker green in status bar?
leggett
commented
10 years ago Darker green in status bar: #539729
bbodenmiller
commented
10 years ago Design looks great but it's starting to become unclear how this design and The Transit App differ.
leggett
commented
10 years ago Hmm... I downloaded The Transit App and I could only see transit directions, no simple "when is the next bus". But looking at their website, it looks like they have such a mode, maybe it just doesn't work on L yet. Do you have an idea of what differentiates OBA from Transit (philosophy? target user? problems you are solving? better data? etc?).
leggett
commented
10 years ago Downloaded Transit App (TA) on a K device. You're right, it is very similar to what I was suggesting – promise I didn't copy! I love how immediate and responsive TA feels.
There are some subtle differences but they may not all be for the better:
Happy to reconsider the design if you can give me more information on what the difference should be between the apps (different focus, target user, etc). If the data source is the same for both apps and both are free, maybe both apps don't need to exist?
paulcwatts
commented
10 years ago I would say a key difference is that OneBusAway is a non-profit organization.
We'll never serve ads, and we won't make our users the products that we sell to others. We also have a social equity component as well, which motivates @caitbonnar's work providing tools to help blind and low vision riders.
The OneBusAway organization also provides tools for transit authorities beyond the mobile apps -- for instance, the OBA server code is what powers MTA BusTime in NYC, and they don't use the mobile apps.
caitbonnar
commented
10 years ago @paulcwatts :+1: :)
bbodenmiller
commented
10 years ago Clearly the OBA apps should remain, my main point however is that some thought should probably go into how the OBA apps would like to distinguish themselves from the other transit apps. The Transit App is more polished and works in many cities (e.g. somewhat might visit here from SF and still be able to use the same app) so I can understand why users may flock to it. OBA generally still has better data since The Transit App assumes a route is either showing real time status for all upcoming trips or none (e.g. if next bus does not have real time status but following bus is already reporting it The Transit App will only return the time until the following bus).
Anyways back to the design discussion. I'm all for the least amount of clicks to find what I'm looking for. Generally at launch I want to know when the next bus I can take is.
leggett
commented
10 years ago So I think both apps (OBA and TA) are trying to solve roughly the same problem. TA has a broader scope/functionality but what I'm hearing is OBA has better data. Or maybe the same data but just gives better access to it?
To differentiate (which isn't really a good goal by itself), you want to find places where you can better solve people's problems (a good goal). Since there isn't funding/staff to do research or user testing, I'd recommend building the most minimal app that addresses the core needs (when is the next bus) for a specific target audience (all locals, including those with poor vision and older phones) and build from there based on feedback and any aggregated usage statistics.
The stream of cards from bottom that scroll up to cover map (let's call this the Map Stream) isn't something TA invented -- as far as I know, Google Maps did. And it is superior to hiding information behind tabs and taps. I think better connecting the information in the cards to the stops/routes on the map will result in a different and more intuitive experience.
What I don't know is if the Map Stream design lends itself to strong accessibility and backwards compatibility.
Thoughts? I'm also happy to bow out if I'm just stirring the pot and not actually helping.
bbodenmiller
commented
10 years ago Thanks for your comments @leggett. I think you are definitely helping the conversation, if anything I'm the one stirring the pot asking about the TA.
I agree with what you said: build the most minimal app that addresses the core needs. I agree the stream of cards from the bottom is superior to hiding information behind tabs and taps. It would be great if someone was able to do some usability research on various designs and I thought Sound Transit was working on that but I think recent turnover and an unfortunate death has halted that process. I think a good test would be time from app launch until you can determine what you are looking for (time for until next bus, where bus stop is located, route map, route schedule, etc.).
For the record I've asked the TA developers and they use OBA APIs thus the TA and OBA apps use the same data but interpret it differently. I've actually suggested they revisit some of the assumptions they make to address the data issue mentioned in https://github.com/OneBusAway/onebusaway-android/issues/155#issuecomment-58743556.
barbeau
commented
10 years ago In general, OBA is unique because its the only open-source/non-profit transit app that gives transit agencies control over their own destiny. Using our multi-region setup, an agency (or university, etc.) can set up their own OBA server, and their info becomes accessible in the OBA apps (Android, iOS, Windows Phone, Windows 8). Other transit apps (including TA) are closed-source and driven by a commercial entity that could fold or discontinue service at any time (e.g., iOS 6 maps debacle). Open-source nature also allows universities to use OBA for research, including development of features (e.g., accessibility) that commercial entities may not be interested in.
From a feature perspective, IMO OBA is good at getting you straight to the arrival times of the buses you care about via features like stop bookmarking, and we should continue to focus on improving that strength while addressing some of the weaknesses as well. IMO if we end up with a design that is easy-to-use, and it happens to have similarities to the Transit App, that's ok.
@leggett I like your proposal in general (it looks nice!), and any reduction of taps is great. I don't think backwards compatibility is an issue - the bottom sliding window I'm using (so far in the context of bus icons) is compatible back to Android 2.3. But accessibility is a concern, especially with a map driving most of the navigation and list contents - perhaps @caitbonnar would have more input on this.
caitbonnar
commented
10 years ago @barbeau @leggett @bbodenmiller Sorry for jumping in a bit late, I've been trying to get a release out for OBA iOS as well as balance all of my other grad student duties.
Anyway, after interviewing a number of diverse OBA users this summer as part of my research, I'm not sure I necessarily agree that "fewest number of clicks" is what we should optimize for. It should be an important factor, of course, but it's not the essence of usability. I like the idea of simplicity, but as I've found, "simple" can mean any number of things depending on who you ask. For blind and low vision users, are labels clear, and is there a logical organization? Is the UI cluttered with elements? A map-driven interface, while simple from a visual standpoint, is actually one of the least simple things to navigate for this group. At the same time, everyone should still have the option to take advantage of the search and locate mechanisms that a map provides.
I do really like the drawer idea as long as it is accessible - after testing @barbeau's redesign it was a bit tricky to expand/contract, but if there is simple way of navigating through it by moving the finger across the screen or swiping with the screen reader's native controls, I think it would do the job nicely. @leggett your design looks nice and the information is very salient. I would also make sure there's an option to get rid of the transparency for low vision users besides being sure it's navigable by a screen reader.
I think we can (and should) learn from other designs as long as it makes sense, and we aren't infringing on copyright in any way. I wish we had the resources to do more usability studies as well, but we are getting quite a bit of feedback volunteered from the public, so there's that. And honestly, I think accuracy and presentation of the real-time data are actually the two things I hear about 90% of the time, rarely it's anything about efficiency/look of the UI. But I do think these are changes we should make if it is improving the learning curve and overall experience of the app.
Anyway, my two cents! I think this is good to talk about. It might be worth discussing cross-platform as well.
caitbonnar
commented
10 years ago A OBA Android user contacted our StopInfo group a week or so ago and was really interested in helping test out the beta version (as well as enter info for stops), so I linked him to the APK. He returned some feedback to me today, which I thought I would pass along, as it has some feedback on the new UI as well:
I figured the switch to the browser and back would be a bit confusing/tedious. Do you know of any way to embed it into the app, similar to the web view controller we use in iOS? If this is too much work, we can also link it back to the app directly from StopInfo if there is some way of using a custom URL scheme or some other mechanism. In iOS, we use http://onebusaway.
barbeau
commented
10 years ago @caitbonnar Thanks for the feedback, and sorry for the delayed response. I've been buried in a few things this week but hope to review this more closely soon.
caitbonnar
commented
10 years ago @barbeau Sure, no worries! Just wanted to make sure it got to you before I forgot. :-)
jrharshath
commented
10 years ago Hi all! I'm revisiting this thread after a while! I had made some screen comps a while back, so adding them here for completeness' sake.
The difference I see between my version and Transit is that I'm focussing on stops directly. I'm going to do a study very soon to see how many people use the same stops over and over for their trips. My thought is that if people use the same stops a lot, it would make sense to prioritize showing stops rather than routes.
I think my favourite icon needs more work though. I went with not showing all buses on the map in the beginning to reduce clutter. Also, the map is being shown at a fairly zoomed in level. I think it would be good to show routes, favourite stops and the user's location when the map is zoomed out beyond a point.
Let me know what you guys think!
PS: sorry for the huge images.. can't get markdown to resize it :/
jrharshath
commented
10 years ago I came up with another treatment of the same concept... I replaced the unnoticeable "dropdown" with a tab bar on the bottom drawer.
As part of the current work I'm doing on OBA Android, I'd like to refresh the UI a bit to bring it in line with modern Android UI components/design (especially the bottom sliding drawer used in apps such as Google Maps). In particular, I'd like to make the main ways of viewing stops (Map, Favorites, Recent) more apparent, and reduce the taps and hard transitions (e.g., opening new Activities) needed to get from the map to the arrival times and route displays.
I've drafted an initial mock-up in a Google Drawing. The drawings are also shown below in-line for easier iterative review/comment.
Please provide feedback!! These are considered a starting point for conversation.