iOS editor keyboard requires additional taps for basic actions

Hey! I have found that the new iOS keyboard requires multiple steps to do things that used to be simple taps. Stuff like page links, bold italic etc used to fit above the keyboard but now require opening the full smart keyboard with an extra tap.

Could you share some thoughts on this design decision? Ideally the primary shortcuts would be there but you can still tap a button to expand the keyboard.

Thanks!

1 Like

Hello,

based on the feedback we got over the years, we understood some user find hard to discover some of the editor functionalities hid in the scrolling accessory view currently on top of the keyboard in Bear. And Iā€™m referring to pretty essential functionalities such as undo/redo, indentations and links. Having a single access point for every functionality partially solves this problem.

We can theoretically move some functionalities outside the custom keyboard to the accessory, as we did for folding and hashtags, but I suspect it might get tricky because those ā€œmain functionalitiesā€ might be subjective to each user.

Hi, I think it would be a great option if the user can manually select what can be shown on the ā€˜bear-styleā€™ tool bar, and still have access to all tools on the custom keyboard. An app called ā€˜Minimalā€™ allows you to change the order of the tools.

3 Likes

I think this is an excellent idea and would support the idea of a user customisable quick access toolbar. This would be a small set of commands which could be rapidly accessed from the keyboard without needing to access the advanced BIU keyboard.

Iā€™m sure different folks would want different functions to be available here. For example I primarily use the Mac client and when Iā€™m using the iOS version Iā€™m generally doing outlining i.e. setting up bulleted lists - for this reason Iā€™d really like to have the indent & outdent commands readily available.

Thanks for all the work youā€™re doing on Panda - itā€™s head and shoulders above all other apps out there :slight_smile:

1 Like

Though I do understand the rational for the new design, some optional functions might really help, especially on the iPhone. I think something like Eleanorā€™s suggestion could work very well.

Also in regards to the tool bar on iOS ā€“ also discussed in this thread ā€“ I am still confused by the very dominant icon and prominent position for the option to hide the keyboard.

On the iPhone screen this grabs a lot of attention; in addition to the dark background. The lighter background of the tool bar in the current Bear.app seems to be a better ā€œtransitionā€ between interface and notes.

1 Like

I actually prefer the existence of the hide keyboard as it means I do not have to swipe up and down the document to close the keyboard. On a completely different note, I wish bear (or panda) to be smarter and do not let users to open the links (to different notes/ websites/ even tags) while the keyboard is on aka editor mode, so I can stop accidentally going to places I donā€™t want to go at the moment. :joy:

1 Like

I think the accessory keyboard is great for discovery, but I assume we donā€™t want to improve discovery for users who arenā€™t using features at the expense of speed for users who already use all the features. I really do find it slower in Panda given the extra tap, as compared to the existing ā€œribbonā€ (which I find quite an elegant solution!)

In terms of what shows up there, as others have said, customizability would be great! But the existing ribbon (in terms of what shows up on the leftmost side of it) could give a hint to defaults. Iā€™ve gotten used to that in terms of being able to quickly access page links, header, list, divider, which are all visible at the top by default.

Thanks for your response and consideration here!

1 Like

I agree, that the hide keyboard button is way better than swiping up and down! In my post I was just suggesting a ā€˜lighterā€™ icon and maybe different position, both in relation to the styling button (showing the extended keyboard).

// While I was referring to the iPhone version, I just noticed that the iPad version uses a different icon and position.