Make command bar cursor more apparent

[andrewtavis]

This issue is to add a minor UI element to Scribe keyboards where the command bar would be shown to be actionable when commandState == true in KeyboardViewController.swift and CommandVariables.swift. As of now the cursor and prompt are static and in one color, but adding a blink or greyed out "write" in the keyboard language would make it more apparent to the user that they will be typing in the command bar instead.

Changing the prompt to have greyed out text would likely be the easiest solution to this (see image below).

• This issue should also include updating the Translate images in the App Store to show the command placeholder

[andrewtavis]

The above was done by a designer as an example for a blogpost header. This could be used as a guide for doing the greyed out text, which could be keyPressedColor from ColorVariables.swift.

[andrewtavis]

We could also do "Scribe" in greyed out letters to keep it consistent across keyboards.

[SaurabhJamadagni]

Hi @andrewtavis, I would like to help with this task. I am new to iOS Development. It would be really helpful if you could give me a few pointers as to what needs to be done. For the greyed out letters, I was wondering if adding a placeholder text property to commandBar is the solution?

[andrewtavis]

@SaurabhJamadagni, thanks for reaching out! I'd be very happy to give some direction on this. Your suggestion to add a placeholder text is definitely in the right direction, but then this placeholder text would only be viewable when commandState == true (we want to keep the UI clean when the user is not in command mode). Big thing as well is that we need to make sure that when the user starts typing the "write" prompt goes away, but then if they delete back to the start of the prompt it needs to return.

Let me bounce another idea off of you, as it's been a while since this issue was made: we have the general problem that we want the user to better understand that they'll be typing into the command bar instead of the proxy, a textDocumentProxy defined in KeyboardsBase/KeyboardViewController.swift. In custom keyboards the proxy is the normal text field like the search bar or message input. Do you think that maybe a simple animation of the commandBar could also do the trick? So say we simply do a blink of the commandBar color, which will draw the user's attention to the prompt more distinctly?

Would be great to get your feedback on the above, and I'll also check with the designer on this too :) We're currently in the midst of redoing all the App Store images 😊

[SaurabhJamadagni]

@andrewtavis When I type, my attention tends to go to the place where I am typing in the document automatically. So I am just wondering if animating the command bar would be distracting? I completely understand that the whole point is to get the attention of the user to the command bar. But also we wouldn't want the user forgetting the context of what they were typing with the looking back and forth 😅

What if instead of animating the commandBar, we have some placeholder text and animate the placeholder text. It would grab the user's attention but also be subtle enough to not distract. Just trying to brainstorm here. I hope I am being of some help.

While you check with the designer, is there anything else I can help you with?

[andrewtavis]

@SaurabhJamadagni, you very much are being of help! I actually totally agree with what you said. The designer said we'd definitely need to prototype any significant color change to the UI like changing the command bar's color. I honestly like my idea less than the original and yours now 😄

The first task would be to add the placeholder text anyway, so let's do that, and we can see if we want to animate it later. Looking into the files and helping you understand what's going on here in relation to all this:

• When a user presses a command button like translate, conjugate or plural, the commandBar text is changed in the case statements in the following lines:

  Scribe-iOS/Keyboards/KeyboardsBase/KeyboardViewController.swift

  Line 1085 in 076650f

  // Switch to translate state.

• You can see commandBar.text = translatePromptAndCursor and the like, with these prompts coming from the interface variable files for each keyboard (German's with the needed part below):

  Scribe-iOS/Keyboards/LanguageKeyboards/German/DEInterfaceVariables.swift

  Line 109 in 076650f

  func setDEKeyboardLayout() {

• Firstly we're going to need to add a placeholder text to each file. We can make an empty string variable commandPlaceholder in ScribeFunctionality/CommandVariables.swift in the // Command input and output variables. section, and then from there we can make versions of it in each function like setDEKeyboardLayout.
• Then we'd need to make variables for each command in setDEKeyboardLayout and the like that include the placeholder text, so translatePromptAndPlaceholder = translatePromptAndCursor + commandPlaceholder.
• We'd then need to set commandBar.text to translatePromptAndPlaceholder and the others instead in the above post button assignment, and then change it so that as soon as the user types the prompt would go away (more on this later).
• And then we'd need to change the color of the prompt text so that it's a bit more grey. The CommandBar class is a UILabel, so it looks like something like the answers to this SO question should be what we want :) We should be able to grey out the text using indexing, and basically go from the index of the length of translatePromptAndCursor and similar variables.
• I'm not sure if we need to replace the prompt if the user starts typing and then deletes back to the start 🤔 What do you think?

[andrewtavis]

First a decision of what the prompts would be needs to be made, and then you could start making those initial changes to add the needed variables while we iron out the rest 😊

Here's the conjugation prompt for German with two different styles of prompt:

I'm kind of leaning towards not including the ..., but what do you think? Also checked with the designer on his opinions :)

And for the actual prompts, are we doing "write" in the various languages, or "type"? "type word"?

[andrewtavis]

While you check with the designer, is there anything else I can help you with?

And for this, another very simple issue is #168. Feel free to let me know if you have interest in that issue, and then I can give a similar summary :)

[andrewtavis]

We might also want to consider a full prompt specific to the command like below ("input Verb" in German):

[SaurabhJamadagni]

I'm kind of leaning towards not including the ..., but what do you think? Also checked with the designer on his opinions :)

And for the actual prompts, are we doing "write" in the various languages, or "type"? "type word"?

"write" would be more inline with the name of the app in my opinion and better in terms of consistency throughout languages. I also prefer the ... Maybe could also try adding them after the word. Example, schreibt...

[SaurabhJamadagni]

And for this, another very simple issue is #168. Feel free to let me know if you have interest in that issue, and then I can give a similar summary :)

Yes I would love to work on that issue till the intricacies of this issue are figured out. Initially I was confused between the two issues. But because of my current limited knowledge, I just chose the one which looked simpler. It would be really helpful if you could give a similar summary for issue #168. It is really helping me understand the project better! Thank you so much for taking the time for helping me understand the project! 😊

[andrewtavis]

I also prefer the ... Maybe could also try adding them after the word. Example, schreibt...

Yes, I'd say this one or without the dots 😊 Here's a screen of it :)

[andrewtavis]

Yes I would love to work on that issue till the intricacies of this issue are figured out. Initially I was confused between the two issues. But because of my current limited knowledge, I just chose the one which looked simpler. It would be really helpful if you could give a similar summary for issue #168. It is really helping me understand the project better! Thank you so much for taking the time for helping me understand the project! 😊

My pleasure! I'll head over there and type something out 😊

[andrewtavis]

We might also want to consider a full prompt specific to the command like below ("input Verb" in German):

@SaurabhJamadagni, the designer said that he liked this version the best as the directions are very clear, so what we should look to do is make three different prompts:

• "Enter word" for Translate
• "Enter verb" for Conjugate
• "Enter noun" for Plural

Let me know how it sounds on your end, and hope you had a nice weekend!

[SaurabhJamadagni]

Let me know how it sounds on your end, and hope you had a nice weekend!

Yes, the clarity absolutely makes sense. It would definitely improve user experience. Also like discussed before, is any form of animation going to be added? I would love to hear your and the designer's take on that too. We could surely get started with implementing it. Let me know whenever you want me to start working on this issue.

I did have a pleasant weekend. I hope the same was true for you :)

[andrewtavis]

My weekend was also very nice! Am going to be pushing the new App Store image designs later today, and socially had some nice days 😊

Let's not do animation as of now, and once the greyed text is finished we can make a new issue to discuss animation if we decide we need it. It might be a bit complex to add to a field that the user needs to be able to type into, so let's do a simple implementation and iterate. You are free to start working on this. The big difference is that instead of commandPlaceholder as before we'll have translatePlaceholder, conjugatePlaceholder and pluralPlaceholder. I'm very happy to explain that a bit more if you'd like me too :D

[SaurabhJamadagni]

Hi @andrewtavis, sorry I was away for a couple of days.

Coming to this issue, if I am not wrong, the three variables translatePlaceholder, conjugatePlaceholder and pluralPlaceholder should go in CommandVariables.swift.

My guess is the bigger part of the changes will happen to the KeyboardViewController. Or will the changes happen to the individual files such as Keyboards/KeyboardsBase/ScribeFunctionality/Plural.swift. Same for the conjugate key and translate key.

I tried to navigate a bit on my own, but I think I will need a little bit of an explanation. Could you please help me?

[andrewtavis]

@SaurabhJamadagni, all fine on the timing. I've been busy the last few days too :)

Yes, CommandVariables.swift would be where to put those variables, and then their translated versions for each language need to go into the respective set layout functions like setDEKeyboardLayout in DEInterfaceVariables.swift.

Very true that the main challenge will be in the view controller. Most of the actual changes will be in there, and that's where we'll need to change the color and make sure that the prompt disappears after the user types something.

General ideas on this, and let me know if you need more help:

• We need empty placeholders for translatePlaceholder, conjugatePlaceholder, pluralPlaceholder, translatePromptAndPlaceholder, conjugatePromptAndPlaceholder, and pluralPromptAndPlaceholder
  • These go in CommandVariables.swift
  • Each of these needs to be assigned in setDEKeyboardLayout in DEInterfaceVariables.swift and the other set keyboard layout functions
  • We can just go off what Google translate says for the prompts
  • Ex, German: Wort engeben (translatePlaceholder), Verb eingeben (conjugatePlaceholder), Nomen eingeben (pluralPlaceholder)
  • For each we then have translatePromptAndPlaceholder = translatePromptAndCursor + translatePlaceholder and the like
  • The above is enough for a first PR 🚀
• Then we need to dig deeper into KeyboardViewController.swift to figure out how to change the prompt to the basic one after the user starts typing
  • What I mean by this is that first it's Plural: │ Nomen eingeben, and then the prompt changes to Plural: chars_user_typed│ after they start entering text
  • This can be a second PR
• Then once we have a black prompt that disappears when the user types, we need to figure out how to make the prompt grey
  • Plan for this is again to use the answers to this Stack Overflow question
  • This can be a third PR

Let me know how this sounds!

[andrewtavis]

How are you doing on your development environment? Have you been able to get Scribe up and running on an emulator? Happy to help with that if you need some 😊

[SaurabhJamadagni]

Hi @andrewtavis, sorry for the no updates in a while. I was trying to navigate the codebase a little, to the best of my understanding. For this issue, I am thinking of the following. Could you confirm I am headed in the write direction and I'll start updating the code immediately.

1. Create a inputStarted boolean in CommandVariables.swift that checks if the user has started typing.
2. In the default case of executeKeyActions(), we will change the boolean to true.
   

   Scribe-iOS/Keyboards/KeyboardsBase/KeyboardViewController.swift

   Line 1373 in 2e0e2b7

   default:

3. Will add a if-else block that changes the translatePromptAndPlaceholder to translatePromptAndCursor and so on for conjugate and plural.

This is so just for the part where we get rid of the placeholder when the user starts typing. Does this sound correct? After this is up and working, I will figure out how to get the placeholder back after user deletes the input. Trying to tackle the issue piece by piece 😅

[andrewtavis]

Hi @SaurabhJamadagni, no worries on no update in a while :) Thanks for checking in!

1. Maybe commandInputStarted would make it more explicit. I'm wondering if we need a named variable for this or if we should just do conditionals. The ones I'm thinking we need are:

• commandState == true
  • We check to make sure that a user hasn't pressed a key like 123, ABC, or another that switches the view
  • If it's a normal key, then switch the command bar text to remove the placeholder
• commandState == true && getTranslation == true && commandBar.text = translatePromptAndCursor
  • This would be maybe in the block for case "delete":
  • The user has deleted back to the start of the prompt, so we need to switch to translatePromptAndPlaceholder again
  • We'd do similar conditionals for conjugate and plural

2. Something I'm realizing is that the above switch back from translatePromptAndPlaceholder and the others needs to happen before the character is added to the command bar, as if we insert the character and then change commandBar.text to remove the placeholder, then we lose the character that the user typed. Maybe what needs to happen is that we need to do a function within CommandBar.swift that does the boolean checks above and switches the commandBar.text if needed? That way we can do something simple like commandBar.conditionallyRemovePlaceholder(), which can be called after default: as you suggested, as well as case spaceBar: to make sure the placeholder goes away if the user presses space and case "'", which is needed to make sure we switch back to letter keys effectively.
3. Exactly! commandBar.text = translatePromptAndCursor and the like if commandState == true && getTranslation == true and the user hasn't pressed a key to switch the view.

Another thing is that we need to make sure that the characters are being entered properly and that the prompt can't be deleted (there's a check in there similar to those above that blocks delete if commandBar.text = translatePromptAndCursor). My assumption is that insertPriorToCursor will function fine, and commandState == true && allPrompts.contains((commandBar?.text!)!) is the conditional to prevent the command prompt from being deleted, which should also work fine in this case as that's all the ones without the new placeholder texts. Just typing this out, I think we're good, but then it's good for you to know how these things work 😊

[andrewtavis]

The above is a lot of text, so let me know if you have questions! I think we're really close on this 😊

[SaurabhJamadagni]

Maybe commandInputStarted would make it more explicit. I'm wondering if we need a named variable for this or if we should just do conditionals.

I was considering a separate variable because I didn't want to add to the sudden crashes that might be happening due to booleans getting crossed as we had discussed earlier. Is that something we should worry about right now or should I work on getting some implementation in place first? Sorry for the confusion 😅

Something I'm realizing is that the above switch back from translatePromptAndPlaceholder and the others needs to happen before the character is added to the command bar, as if we insert the character and then change commandBar.text to remove the placeholder, then we lose the character that the user typed. Maybe what needs to happen is that we need to do a function within CommandBar.swift that does the boolean checks above and switches the commandBar.text if needed?

That is a great point! This would also bring all the checks in one place instead of having to look for the individual cases.

Another thing is that we need to make sure that the characters are being entered properly and that the prompt can't be deleted

Yes I did observe that when I ran the simulator. I was able to delete the prompt as well. I was just about to ask about it. Thanks for clarifying :) I'll just change the check from commandBar.text = translatePromptAndCursor to commandBar.text = translatePromptAndPlaceholder to stop the prompt from gettind deleted. Thank you for your valuable feedback on my approach! 😊

[andrewtavis]

That is a great point! This would also bring all the checks in one place instead of having to look for the individual cases.

I think that this is likely the best method, and it also abstracts away from KeyboardViewController.swift which is so massive 😅 In this case we wouldn't use a boolean variable per your question above :)

Yes I did observe that when I ran the simulator. I was able to delete the prompt as well. I was just about to ask about it. Thanks for clarifying :)

We'll just have to keep an eye on this and test it to make sure that it doesn't delete and that the commands go through 😊 Sounds like you're making good progress! Feel free to send along an initial PR and we can talk about where you're at :D

[andrewtavis]

@SaurabhJamadagni, coming back to the issue to continue the conversation :)

Again, thanks so much for your work in #175! Really well done - we're almost done with this! Part 3 is likely a bit trickier than we think, but maybe not. Again I think that this Stack Overflow question should be most of what we're looking for as far as coloration - we can use the index coloration with the color change length based on the length of the placeholder and index starting based on the length of the prompt (plus one as we have a space between as of now 😊). I think that we can do the coloration within conditionallyAddPlaceholder, and we can remove it within conditionallyRemovePlaceholder, but let me know if you think something else would be better!

A big question would be which grey for both light and dark mode. I played around with it a little bit, and I think that if we want to use colors that are already defined we can use commandBarBorderColorLight and commandBarBorderColorDark. The below mockups use those for the placeholder color:

Let me know how you feel about the colors :) FYI I also just made keyPressedColorLight and keyPressedColorDark a little bit darker as I thought both the pressed colors should be a bit more distinct from the regular keys.

Happy to give more directions on this if needed. Not sure what your schedule is, but my hope would be we could get this finished by Sunday so that I can do a release that evening. I have a presentation on Scribe at a Berlin Swift coding group on Wednesday, and it'd be great if this could be implemented by then (App Store Connect will check new releases within 48 hours). If not, no stress as I'll still show the WIP on the emulator! 😊

[SaurabhJamadagni]

Happy to give more directions on this if needed. Not sure what your schedule is, but my hope would be we could get this finished by Sunday so that I can do a release that evening. I have a presentation on Scribe at a Berlin Swift coding group on Wednesday, and it'd be great if this could be implemented by then

@andrewtavis, I'll do my best to get it done. I had to send my laptop for a battery replacement today as it had clocked a lot of cycles and needed immediate service. I should have it back by tomorrow. In the worst case that I am unable to finish it or the laptop delivery is delayed I'll let you know in advance. I hope that is alright. But for the most part, I think I can get it done by Sunday. 😊

[andrewtavis]

Sorry to hear about the computer problems, @SaurabhJamadagni! Just let me know, and again no stress on if it can't happen by Sunday :)

[andrewtavis]

Hi @SaurabhJamadagni, wanted to draw your attention to the upcoming Wikimania 2022 Hackathon 😊 Generally these events bring people together online to work on Wikimedia tasks and give presentations. I participated at the last hackathon and worked a bit on Scribe-Android, and Scribe should be able to participate again at this one. The email just went out earlier today.

Basically we'd work a bit on Scribe over those few days and then present what it is we've been able to achieve afterwards. If this is something you'd be interested in, then we could make a plan of some interesting things we could work on.

Just sending this along to check your interest :) Figured it might be a fun experience for you 😊

[SaurabhJamadagni]

Basically we'd work a bit on Scribe over those few days and then present what it is we've been able to achieve afterwards. If this is something you'd be interested in, then we could make a plan of some interesting things we could work on.

Thanks for considering me @andrewtavis! I would be thrilled to participate. The first day timings seem a bit tricky by my timezone (IST) but I'll help out as much as possible haha. Am I required to register anywhere or do you just register as one team? This sounds like a fun opportunity! Thank you 😊

About the current task regarding placeholder text, my laptop seems to have given up. I am currently using a borrowed machine from my sister. Hoping to set up git and the project locally by today. I played around with attributed texts a bit a few hours back. I should have an initial PR soon!

[andrewtavis]

My pleasure to include you, @SaurabhJamadagni! I figured this would be a fun experience, and it's good to have Scribe folks show up to Wikimedia events so we can keep the connection strong.

The first day timings seem a bit tricky by my timezone (IST) but I'll help out as much as possible haha. Am I required to register anywhere or do you just register as one team?

No worries if you can't make the first day. These things tend to be informal. It'd be good if you create a Wikimedia account prior to this so that you can sign up, and I'll reach out to see if there's a chance for a talk (maybe not this time). Do you have any Wikimedia accounts yet for Wikipedia or something? If not, I'm pretty sure creating an account on wikimedia.org will make a global account for all Wikimedia projects (projects are what Wikimedia calls things like Wikipedia and Wikidata).

Big thing is that we should have three minute slots to present what it is that we want to work on and what it is that we achieved on the first and last day respectively. From there we can work on things and also attend some talks on Wikimedia related topics. We can connect before then and make a plan, and you'd be welcome to present what it is you worked on :) People are super welcoming, so no stress about this!

About the current task regarding placeholder text, my laptop seems to have given up. I am currently using a borrowed machine from my sister. Hoping to set up git and the project locally by today. I played around with attributed texts a bit a few hours back. I should have an initial PR soon!

Sorry to hear about your further computer troubles, but nice of your sister to let you use hers! Again no stress on the PR. Get to it when you can, and hope you can have a functioning machine of your own as soon as you can! 😊

[SaurabhJamadagni]

Do you have any Wikimedia accounts yet for Wikipedia or something? If not, I'm pretty sure creating an account on wikimedia.org will make a global account for all Wikimedia projects

I currently don't have an account but I'll create one soon.

Big thing is that we should have three minute slots to present what it is that we want to work on and what it is that we achieved on the first and last day respectively. From there we can work on things and also attend some talks on Wikimedia related topics. We can connect before then and make a plan, and you'd be welcome to present what it is you worked on :) People are super welcoming, so no stress about this!

That sounds super exciting! Makes me a little nervous but I guess that is part of the experience 😅

Thanks for including me! I am looking forward to it!

[SaurabhJamadagni]

Hi @andrewtavis! I wanted a little bit of your help 😅

• I tried making the placeholder an NSMuttableAttributedString inside the conditionallyAddPlaceholder function, but that affects the checks inside the conditionallyRemovePlaceholder function.
• I also tried to create a function that just colorizes the prompts but it was still difficult to factor in the checks while removing it conditionally.
• This led me to think maybe I can create a coloredPromptAndPlaceholder variable and assign it a value in each of the language interface variable files like we previously did. This would help with the checks using the isEqual method. But to do this we will have to import UIKit in every interface variable file as otherwise, it won't let us use UIColor. Do you think that is an acceptable solution?

I would love to hear if you have any other approaches in mind. It could really be of immense help. Any form of brainstorming could also maybe help me find an alternate direction. Do let me know :)

[andrewtavis]

Hi @SaurabhJamadagni, sorry for a late reply to this :) Have had a relaxing day before starting a new job tomorrow.

• This led me to think maybe I can create a coloredPromptAndPlaceholder variable and assign it a value in each of the language interface variable files like we previously did. This would help with the checks using the isEqual method. But to do this we will have to import UIKit in every interface variable file as otherwise, it won't let us use UIColor. Do you think that is an acceptable solution?

This sounds like a fine solution to me :) Totally fine to add another variable and add UIKit to the files that need it. Generally what I was thinking is that the PromptAndPlaceholde variables would be two colored and assigned, and then when that's not assigned then the default coloration is applied.

Let me know if you have further questions 😊 Feel free to do the above method and send along what you can get done!

[SaurabhJamadagni]

Congratulation on the new job @andrewtavis! I wish you the best! I will try to get the implementation in place. Thanks for your input. 😊

[andrewtavis]

Thank you for the congratulations and well wishes, @SaurabhJamadagni!! :) Looking forward to the PR 😊

[andrewtavis]

All done here, @SaurabhJamadagni!!! I'll work on #176 later this week and do the release 😊 Thanks again so much for your hard work 💪 Feel free to let me know what else you might have interest in doing here, or I'd be happy to make some suggestions :)

[andrewtavis]

Just played around with it a bit more :) Really looking forward to v1.4.0! 🚀

[SaurabhJamadagni]

Feel free to let me know what else you might have interest in doing here, or I'd be happy to make some suggestions :)

@andrewtavis, if you have any suggestions do let me know. I would be glad to be of help. Else, I'll browse through the issues today and let you know! Thank you for your help with this issue! It made all the difference 😊

[andrewtavis]

We can do a few more before the hackathon, @SaurabhJamadagni :) What first comes to mind is #165, which I’d love your feedback on, and then #178 should be very simple if you’d like to do it :)

[SaurabhJamadagni]

We can do a few more before the hackathon, @SaurabhJamadagni :) What first comes to mind is #165, which I’d love your feedback on, and then #178 should be very simple if you’d like to do it :)

I would be happy to jump on both issues. I'll leave my thoughts on issue #165 in its corresponding comments. You can assign me these two issues, @andrewtavis. I would be happy to work on them :)