search

scribe-org / Scribe-iOS

iOS app with keyboards for language learners
https://apps.apple.com/app/scribe-language-keyboards/id1596613886
GNU General Public License v3.0
128 stars 79 forks source link

Add menu to Scribe app #16

Closed andrewtavis closed 1 year ago

andrewtavis commented 2 years ago

Terms

Description

This issue is for discussing and implementing a menu with settings to choose which Scribe functionality is available or order how commands are displayed when the Scribe key is pressed. There could be the potential that a user would not need one of the Scribe command buttons, or when more commands are available they'd want to order the commands so that some are easier to access than others (with more commands there likely will be some kind of meatball menu where the extra ones are located, so the user could choose their main ones). Also system functionality like the double space period shortcut could be removed.

Edit: note that this issue now encompasses only the multiple screens for the Scribe app, with separate sections then being added in other issues :) This branch contains an example of how the app screens should be reworked 😊

andrewtavis commented 2 years ago

This would be best achieved by a hamburger menu at the top right of the app screen.

andrewtavis commented 2 years ago

This issue will be done with a settings view that has the following options:

andrewtavis commented 2 years ago

A back button should be added to each page that's not the home screen, with a swipe right also potentially being used as a way to get back to the original screen.

andrewtavis commented 2 years ago

The following would be the potential icons that would be used for the menu (mostly SF Symbols):

wkyoshida commented 2 years ago

Like alluded to here, @andrewtavis , what do you think of potentially having the MVP for the menu be only the following?

I'm mostly thinking that these would be the easiest ones to implement, since they would mostly just be different views/pages. Settings will end up being more complex, since it would require "manipulating" logic for the keyboards, isn't that right? I'm thinking an MVP with the above 4 could at the very least already give us the backbone for the menu so more options can get added later.

andrewtavis commented 2 years ago

Your idea for the MVP makes total sense, @wkyoshida 😊 I think those as base views that are populated with text and simple icons is exactly what we should do, and then as you suggested adding further features would be separate issues. This isn't too hard, ultimately. Just need to jump in 👨‍💻

There are a few things that are more pressing than this now, specifically #96, but then I'm hoping to get some suggestions for that at a meetup I'm going to on Thursday (will report back to the team 🙃). It's also a question of what the menu UI would look like, but I'm talking with my friend who did the designs in a few weeks as well. From there we'll be good to go 🚀

Austinate commented 2 years ago

Hi there!

I'd like to share some suggestions if you don't mind :)

1) Maybe we could consider using TabBar instead of hamburger menu? They can be a bit more convenient (subjectively, of course) to the user from the UX perspective. So, for example, we might have 3 following tabs: 1) Home 2) Settings 3) About (Privacy Policy, Contact, Wikidata etc)

Or we could consider having just 2 tabs: Home and Settings, since sometimes it's natural to include attributions, contact options and ToS into the settings section of the app.

You can check Apple's Human Interface Guidelines, it shares some ideas regarding usage of tabbars, side menus etc.

2) Since minimal app target is 13.0 probably we could consider building the menu in SwiftUI? Older iOS versions might require additional attention and workarounds, but we might benefit from the flexibility of the approach overall

andrewtavis commented 2 years ago

Ahhhhhh shittttttt 🙇‍♂️😊

Great to hear from you! I actually was just working on this yesterday, and totally agree that a TabBar would be the way to go. I also was thinking that three options with home, settings and about would be best too, as there will be enough going on for settings like options for specific keyboards that it'd be good to have it in its own tab. As far as SwiftUI is concerned, you know better than most that it's all a bit new, but I 100% trust your intuition on this and am very happy to implement in this way.

Plan was actually to throw something together in the designs tonight as I got really excited just mapping it out a bit. Should be easy enough to do a basic prototype/click dummy, so hopefully it'll be ready in the next few days! Will write in here when it is and we can discuss 🚀

Austinate commented 2 years ago

Hey hey! Glad to hear back from you too! 👋 😄

As far as SwiftUI is concerned, you know better than most that it's all a bit new, but I 100% trust your intuition on this and am very happy to implement in this way.

I think that might be an interesting exercise and it will allow us to be more flexible with the designs, however if we decide to go that route it might be worth to bump the min required iOS version to at least 14.x or even 15.x — it's a common practice to support only 2 latest os versions.

Maybe we could review the stats for iOS version usage from AppStore Connect to understand who using the app?

Plan was actually to throw something together in the designs tonight as I got really excited just mapping it out a bit. Should be easy enough to do a basic prototype/click dummt, so hopefully it'll be ready in the next few days! Will write in here when it is and we can discuss 🚀

Awesome, will wait for the update!

P.S. I've spent some time to create a small SwiftUI showcase for you in my branch it contains: 1) Early stage recreation of the existing app menu 2) Small example on how to create tabs in SwiftUI

https://user-images.githubusercontent.com/4790464/200401079-ffd232a6-3118-413a-b15a-3f1959f3d67e.mp4

This one might be useful at least for prototyping, let me know what you think :)

andrewtavis commented 2 years ago

... if we decide to go that route it might be worth to bump the min required iOS version to at least 14.x or even 15.x — it's a common practice to support only 2 latest os versions.

Happy to bump the minimum version up to 14.x if we'll get some worthwhile functionality from it and avoid some headaches 😊 I just checked, and there are users in 14.x range, but no one's on 13.x at this point :)

I've spent some time to create a small SwiftUI showcase for you in my branch it contains:

Looks great! Glad to have an example to work from too! Thanks for putting all that together 🙏

Hammered away at the design/prototype tonight and was able to get what I hope is a solid baseline done 😊 The link to the page in Figma where it can be found is here. In the off chance that you don't have experience with Figma, you can press the play button in the top right, and then in the options select Fill screen. From there you can click around :) Very basic at this point as far as just switching pages and working toggles, but it's a start! The info icons would be clickable so we can put some information on what the option does without making it too messy :)

Posting an image of it below as well: App Screen Designs

Let me know what you think, @Austinate! Also @SaurabhJamadagni and @wkyoshida, would be great to get feedback from you both as well 😊

SaurabhJamadagni commented 2 years ago

Hi @andrewtavis! The design looks great to me. We should also probably add the large Scribe header to the Installation screen. It is missing from the mockups right now but I find it to be a nice touch haha.

This one

image

Super excited for all the new changes coming to Scribe! It is so awesome! 🚀

wkyoshida commented 2 years ago

Very nice, all! :raised_hands: This is awesome

My curiosity - what would Wikimedia and Scribe in the About page lead to? Would it be something like one of the articles/presentations on Scribe?

Also, we've already touched on some of these already in other discussions, but an interesting thing for later on, I think, could be the ability for the extended customization for all different combinations of keyboards, i.e. for each keyboard the user has:

Anyways.. definitely a whole other can of worms to look into later :laughing: but main thing to consider potentially is that perhaps some settings could be global vs others could be keyboard-specific.

andrewtavis commented 2 years ago

The design looks great to me. We should also probably add the large Scribe header to the Installation screen. It is missing from the mockups right now but I find it to be a nice touch haha.

I find it nice too and was kind of missing it :) Is a nice welcome to the app. Will play around a bit and add it in soon 😊

andrewtavis commented 2 years ago

My curiosity - what would Wikimedia and Scribe in the About page lead to?

I'd say for now just a description of what Wikidata is with their logo and an explanation of how we're using it/working with them. Something short to explain it, but not necessarily take them out of the app :)

Also, we've already touched on some of these already in other discussions, but an interesting thing for later on, I think, could be the ability for the extended customization for all different combinations of keyboards, i.e. for each keyboard the user has...

Really good point - that the way that it's set up now it's not being done on a per keyboard basis. I think from the start it makes sense to just have global settings for currency symbols and what the base language is for translation, but there could be a case where someone wants unique values per keyboard. How to set this up in the UI is a question though 🤔

For a reminder though, what needs to be added is:

Those will be updated within the designs in the next few days. Let me know if anything else should be added!

andrewtavis commented 2 years ago

The designs have been updated and now include an app flow for most of what we've been talking about 😊 Again, hit the play button and you can see it in action :) :) Let me know if anything else should be changed 🙃 As far as animation, I'm generally thinking that we can just blink the text for most fields when the user clicks on them.

Scribe App Screen

Some questions:

wkyoshida commented 2 years ago

I think from the start it makes sense to just have global settings for currency symbols and what the base language is for translation, but there could be a case where someone wants unique values per keyboard. How to set this up in the UI is a question though :thinking:

Potentially, it could be dynamic sub-menus for each keyboard that the user has. Something like a Your Keyboards with each keyboard as an option, clicking on an option would lead to the settings sub-menu for that keyboard. By default, Your Keyboards would be empty, but would populate with each keyboard added? Brainstorming.. :brain::cloud_with_lightning:

How do we feel about the flow into sub menus?

I feel like that makes sense

For pages with a lot of text... are we just having the card extend the full length of the page and they can scroll down it?

Hmm.. perhaps? :thinking: I'm thinking that minimizing users having to leave the app would be ideal; so agree that it'd be something in the app still. A card that they can scroll down through, like you said, perhaps could make sense. Keeping with the rest of design elements probably makes sense too; so not just the plain text on a total white background (mostly referring to Privacy policy and Third-party licenses for this). Wikimedia and Scribe can have some liberty with its content; it doesn't have to be just text like with the former two.

Any other comments or concerns? :blush:

Another curiosity - what would Report a bug lead to? Today, I guess bugs are simply reported in the GitHub repos via issues. Would that option be for reporting bugs differently?

andrewtavis commented 2 years ago

Something like a Your Keyboards with each keyboard as an option, clicking on an option would lead to the settings sub-menu for that keyboard.

We'd just need to figure out how to detect which keyboards are installed or not, but would be good 😊

so not just the plain text on a total white background (mostly referring to Privacy policy and Third-party licenses for this). Wikimedia and Scribe can have some liberty with its content; it doesn't have to be just text like with the former two.

Lemme try to add some text and maybe an icon to the page and see how it looks :)

what would Report a bug lead to?

I'd argue it'd go to Issues here, right?

SaurabhJamadagni commented 2 years ago

I agree with keeping the user in the app itself for the privacy policy and licenses @andrewtavis. A scrollable window that shows the document would be a good idea. Something apple provides when they present the terms of agreement when updating OS.

Something of this sort.

image

About the flow of menus, consider the user presses the Default Currency Symbol menu. Wouldn't that mean that the user is inside the Defualt Currency Symbol menus and not Layout? I think it would be confusing to the user if they select the currency menu but the heading says Layout. Maybe, for the sub menus we could only show the sub-heading and on the back button show the title of the section the sub menu belongs in.

A crude example again from apple's sub menus could be:

image

Ignore the About header, here the button could say Layout and then we could have Default Currency Symbol as the main heading in the font that is unanimous with our app.

andrewtavis commented 2 years ago

About the flow of menus, consider the user presses the Default Currency Symbol menu. Wouldn't that mean that the user is inside the Defualt Currency Symbol menus and not Layout? I think it would be confusing to the user if they select the currency menu but the heading says Layout. Maybe, for the sub menus we could only show the sub-heading and on the back button show the title of the section the sub menu belongs in.

I think a mix would be good, @SaurabhJamadagni 😊 Let’s have the back button be the item for the TabBar, the header be what they’re choosing like Default currency symbol, and the sub headline could be replaced with some text explaining what it does. We could also use the same text for the info icons :)

I think this’d be great 😊 Thanks for the feedback!

wkyoshida commented 2 years ago

I'd argue it'd go to Issues here, right?

Yea, perhaps it could. I guess I'm just considering how this bug-reporting workflow would look like for someone on iOS or Android. Desktop is a different case, but for mobile users, it will likely mean opening GitHub on whatever mobile browser they use and attempting to write a bug report there. I find mobile GitHub to be a bit meh to use. Then there's even just the factors that a user would also first need to know how GitHub works and also have an account. Mostly just thinking it could deter some potential bug-reporters. However, I guess people could also just report bugs on app store comments or one of the platforms that Scribe is on (https://github.com/scribe-org/Scribe-iOS/issues/181); so it could be fine to link to Issues

andrewtavis commented 2 years ago

Yes I'd say for now linking to Issues is ok, and we can see where it goes from there :) I don't think that linking directly to the bug report issue template is necessary. Ultimately if they want to contact us, then they can via email as well, which will also be included 😊

andrewtavis commented 1 year ago

Am feeling better from a lengthy cold and am looking at all this now :) A minor note for documentation is that this SO question seems to have a method to detect if a custom keyboard has been installed. If so, and if we can detect specific keyboards within the bundle rather than any keyboard, then we should be able to have settings specific to the installed keyboard 😊

andrewtavis commented 1 year ago

I just finished up the baseline designs and changed the flow to one where the user can first select an installed keyboard in settings. My intuition would be that Settings would be a bit more greyed out if there's not a keyboard installed, and hitting it would trigger a hint to tell them to install a keyboard. Also now included is how the privacy policy and other About screens could look. They can be found in Figma here. Feedback is of course welcome 😊

Once the designs there get the go ahead, the next step would be to check if a dark mode version is feasible, and if so to finish that up by creating the rest of the dark color palette :)

wkyoshida commented 1 year ago

Nice! Yea, I think that if Scribe is able to provide customization on a per-keyboard basis, it could be good :raised_hands:

My intuition would be that Settings would be a bit more greyed out if there's not a keyboard installed,

I am also wondering now though, if it could be good perhaps to also provide a main override for settings. So Settings could have the option to go adjust settings per-keyboard, but also have the same settings be available to just apply generally. Adjusting the main Settings affects all keyboards. This could be useful for the users who'd want all their keyboards to have the same settings anyways; they won't have to do so manually for every single one. So I thought of perhaps two ways of doing this:

Keyboard Settings
- Select installed keyboard:  
  - English
  - Español 
  - ...
- Settings
  - Translation
  - Layout 
  - Functionality

The above keeps the list of installed keyboards as seen in the current Figma protoype, but then has the same settings also already in the main Settings page too that can be used for general override configuration.

Keyboard Settings
- Settings
  - Translation
  - Layout 
    - Default keyboard
  - Functionality

This second idea would be to only have the settings in the Settings page, but then every setting could have a Custom option. So, for example, clicking on Layout's Default keyboard setting could show the user the standard options, QWERTY, AZERTY, etc., but also Custom. Custom could then lead to a dynamically generated menu with the installed keyboards, and each keyboard would have its own QWERTY, AZERTY, etc. options that can be changed/customized if desired.

Let me know if this is unclear :laughing: have to think through how these ideas would play out, and I realize attempting to describe a design idea with just words can get iffy at times; so I can give it a shot in Figma if needed too :+1:

wkyoshida commented 1 year ago

Also now included is how the privacy policy and other About screens could look.

Oh also, very minor comment - just felt that the font for the About pages seemed a tad small. Other than that though, I think the format for how they look seems good :grin::+1:

andrewtavis commented 1 year ago

I am also wondering now though, if it could be good perhaps to also provide a main override for settings. So Settings could have the option to go adjust settings per-keyboard, but also have the same settings be available to just apply generally. Adjusting the main Settings affects all keyboards.

I agree on this :) Let me give another thought to this and we can edit it a bit. Initial impressions are that some form of your first option would be better, as having the per keyboard settings that deep in the menu as in the second version would likely hide this functionality from many. For now I've added an option for All keyboards, but that's just a placeholder for now until we figure out a better way to integrate it all :) I'll talk to the original designer about all of this as well 😊 Also made the font bigger, good point!

andrewtavis commented 1 year ago

I was able to talk with the designer for all this over the weekend. His general feedback was do exactly what we’re planning and that he’ll let me do the Figma from now on 😅 He hadn’t seen my Figma work for a bit and I’d been practicing 😇😊

Specifically his comment was we have what we need to test all this and see how it actually works in a user’s hands, and from there we iterate 🚀

Minor comments have already been implemented: that we need more spacing between the TabBar words and icons, and that we should have a call to action on Settings when the user has yet to install a keyboard. We now have an Install keyboard button that will go away once we detect they’re installed something. Clicking that would take them back to Install, which isn’t much, but we were thinking that a minor nudge back to the install directions would be enough along with some hints.

wkyoshida commented 1 year ago

Clicking that would take them back to Install, which isn’t much, but we were thinking that a minor nudge back to the install directions would be enough along with some hints.

What about directly opening and taking them to the iPhone keyboard settings? Could that make sense potentially?

andrewtavis commented 1 year ago

What about directly opening and taking them to the iPhone keyboard settings? Could that make sense potentially?

Very much so, @wkyoshida, but sadly for some reason this is not an option in iOS as of now. What used to be possible was encoding paths via strings for what you wanted to open in the menu, but I guess this was breaking with multiple system languages... 🤷‍♂️ I've checked on Stack Overflow a lot for this (just did again), and as of now it doesn't seem to be possible. Lots of people saying that their app got denied by App Store Connect or that it passed and then got rejected later.

As of now that button calls UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!). Hopefully at some point they'll add some functionality to get it to keyboard settings directly, in which case we can also remove the directions on the first page and take them right there. This is what we do in Scribe-Android, as this functionality is available there.

wkyoshida commented 1 year ago

Very much so, @wkyoshida, but sadly for some reason this is not an option in iOS as of now.

Oh I see - well, that's a bummer.. Yeah, hopefully it becomes possible to do so, as it would be an easy user workflow, I think.

andrewtavis commented 1 year ago

Closed via #324 🥳 Thank you, @SaurabhJamadagni! Crazy to have this finished 😊