This topic has been created to discuss the design and implementation of a markdown toolbar for the beta editor.
Pixel 2 Android emulator:
The toolbar is pushed off the screen when there isn't enough space for it:
Just to bring my comments from the GH PR:
Note that I'm trying to create all symbols with text (so that the icon color can be changed by changing the text color).
It would be nice if we could use an icon font (annoyingly it seems Ionicons which is used for other areas of the app isn't comprehensive enough for the toolbar buttons) but that would need to be Laurent's decision if he wants to introduce a new icon set.
I think the italics button looks a bit odd (more like a forward slash) but the list is definitely a neat trick.
Apolgies if I'm missing something but I think the inline code button function should work in a number of different ways (to be consistent with the desktop app) - a press with no selected text should just make the `` marks, a single selected line should make an inline comment and a multiline selection should make a code fence.
One problem I've seen with similar functions on other applications is where they try to provide too many functions on the button bar to the point where you either have to scroll or the buttons are tiny, neither are great.
I'm wondering if we can include all the required functionality by grouping some of the elements together, e.g. press and hold the "list" button to select between unordered, ordered and checkbox. Hold the H1 button to select Hx styles > 2 etc. We should probably also have a link syntax option there too.
It's nice, it's looking quite good already and it seems to handle well adding and toggling style. I think the last example wouldn't be valid though? Because the triple ticks should be on their own line to work as a code block.
For the icons, it's fine to add another package if we don't have what we need in Iconicons. If we do add one we should also take into account the general usability of that package, so that we don't need to add a third one later on for another use. So maybe favour something like a FontAwesome or similarly well known package.
Hi
It looks already quite nice. I've mentioned some great toolbars of other markdown apps previously and I especially like the large size of the buttons in MDNotes in ios. My personal preference would be a # instead of headers H1-4. Though this would be more of a markdown direction than html. I'd say for the italics button simply use a serif font.
Looking forward to see it in the app.
Thank you for the feedback everyone!
I've implemented one of the suggestions left on GitHub:
I'm wondering if we can include all the required functionality by grouping some of the elements together, e.g. press and hold the "list" button to select between unordered, ordered and checkbox. Hold the H1 button to select Hx styles > 2 etc.
How about just press the button once to show all the options, then press the same button twice to actually apply it. The reason is that press and hold in general is very poor in terms of accessibility, e.g. older people with reduced tactile sensitivity are unable to use those.
My personal preference would be a # instead of headers H1-4.
I think I prefer H4 to #### in this case — it's much shorter. If we just have H1 and H2 buttons, though, I agree that # and ## could make sense!
I'd say for the italics button simply use a serif font.
I agree that a serif font would be better here!
It looks like I would either need to hardcode different font names for iOS and Android (different fonts are available out-of-the-box on the two different systems) or bundle a serif font with the app (or perhaps make the serif I an SVG).
I agree it is shorter, though how often do you or others in general use H3 and H4? A hashtag button might come in handy in other situations too. Maybe a menu to enable/disable certain buttons and to change the order of the buttons could be an idea?
Some thoughts on the submenu. You could center it one row above the initial button, maybe with some fixed left and right barriers? This would give the advantage (if added) that in case of a false click I don't have to touch the x but could simply click on another button and the submenu would disappear. I don't think it would be good to make it disappear upon a click to the text as there you might have to place the cursor to apply a style.
I'm impressed by the immediate reaction time in your demo. Your screen size seems pretty large to me. Did you also try it with smaller screens and do you consider to scale the toolbar somehow? On my Iphone SE the normal keyboard already takes more than half of the space in joplin. I am left with ~400px of the body. Maybe it is possible to integrate the "done" button or a keyboard down button into your toolbar and remove the native toolbar, as this would give it some space and I assume you're not going for native ios integration anyway.
If you use more than a bare limit of buttons I think you'd have to implement some sliding functionality like MDNotes has. I looked up some display resolutions:
Apple's display resolutions start at 640x1136 px. Is that roughly 1/2 of your current screen resolution? I checked some of the most sold android devices and they seem to start ~720px in width and the android developer site has some resolution spec to support different screen sizes.
@dimi-huer I use h3 fairly frequently, so h1-h3 are common. I often have some sections below a subhead. But, h4 I can't remember ever using, at least intentionally.
I think ideally we would want to have a static toolbar for the vast majority of devices and leave a sliding implementation to the pure outliers at tiny resolutions or high screen magnifications as a concession hence why I'm keen to get a good method of "grouping" so we can have a comprehensive yet clean and simple toolbar (the opposite to what Obsidian seems to do with no fewer than 21 buttons).
I don't think adding config options for something like this is the right way - we could provide an option to turn it off or on for sake of screen real estate (particularly in landscape mode) but I don't think a full customisation option makes sense, we can end up in a cluttered and confusing mess rather quickly.
The Header implementation on Obsidian however actually does appear do do what I partially envisaged where a single tap of H brings up a sub menu with "No heading", "Heading 1", Heading 2"..."Heading 6".
What I originally had in my head was - forgive the amatueur image manipulation:
But I'm not UI expert so by no means is this a requirement and I'm open to being told why I'm wrong.
I think we would want to avoid this, if we can group well enough then it shouldn't be needed.
For example the groups I see as necessary and the items within them would be
I can't decide if Code, Link and Datetime should be integrated into a single "misc" group, I think it depends on the size of the toolbar buttons.
"Link" I also think would bring up an interesting conversation. Should it provide a "template (e.g. []() ) or should it provide a popup prompt asking you for the URL then leave the cursor in the title field (like the desktop markdown editor does).
I'm still leaning towards a font pack that we can include like Fontawesome - if we find a comprehensive one then it means we can use it for all kinds of UI stuff in the future if we find ourselves limited by the current one.
As much as I like the idea I think the "mixed" buttons are confusing and should probably just show the most common one (e.g. unordered list).
Sliding functionality is already implemented for small screens (if menu items are pushed off the screen, the menu becomes scrollable).
For my own future reference: Hiding the up/down/done buttons.
I think I would prefer a popup prompt — it should help keep things consistent if we add a WYSIWYG editor in the future. (Assuming a WYSIWYG editor would use a pop-up prompt).
The current editor setup allows for menus inside of submenus. I was thinking of eventually turning the TeX action into an entire menu (e.g. with \frac, \cdot, etc.). This is because the \ key is somewhat difficult to reach on the default iOS keyboard.
(Of course, while I use the mobile editor to enter math somewhat frequently, this probably isn't very common).
I fully agree with you. A toolbar where you have to search and scroll first isn't functional anymore and doesn't save too much time.
I agree it could end up cluttered. As you quoted Obsidian I had a look at it in the appstore and this menu looks pretty much as what I thought of in case of customizability. Markor has a pretty similar menu.
I feel like it would be a good option, as there are two large user bases (pure markdown and rich markdown/WYSIWYG), isn't it? On a tablet I'd activate more buttons by default than on a phone. I don't know if it is so easy to find a compromise with grouping.
Neither am I. What do you think of a horizontal submenu instead of a vertical one? I'd also like to hear from someone with UI/UX experience.
On the other hand maybe someone would only like to use formatting, headers and lists? Maybe camera (ios does have native OCR, not sure if it can be used in another app), images (attach photo function) and attachments might be a valuable option too. I've just seen the add image in Markor now with a pop up prompt (only in wiki style notes) with four options (search file system, camera, gallery, edit image). If buttons could be added to main toolbar or to a group via a menu it would give full freedom, but I feel this would be rather difficult to implement.
To me the most practical would be [ ]( ) and the cursor focused in the square brackets, but again this is only a personal preference and might not be the most UX friendly way. MDNotes opens a crazy large prompt, but actually the small prompt which is opened by Markor could be more user friendly. Adding a cursor focus to the link description could be quicker than pure markdown.
Insertion of a $ \ ` # is three clicks for each on my keyboard (QWERTZ, iOS). The same is true for square and curly brackets, which makes mobile editing a pain.
Oh nice, I wasn't aware of that.
I am pretty sure you're not the only one and it might be more common on tablets. However, I can see this menu being cluttered. Also, I somehow feel like it shouldn't be added without the option of a customizable menu. With grouping you'd have a two-level submenu. I don't think this would be practical at all. Maybe a formula button with a pop up prompt were you get a new toolbar with a Katex toolbar? I just checked MDNotes again, that's how they do it. I can't think of a much more practical way myself. Something else I've just seen in Markor is that it has a different default set of buttons for ToDo's.
I assume this is a beta test. How can I install it? I'd love to test these features. I do a lot of writing just about every day on an 8" tablet.
iOS/Android and with git is strongly recommended!Only recommended if you have experience with
gitand the command line!
react-native development environment (see the documentation). Be sure to pay attention to the deploying to a physical device section!Copy the clone URL:
Follow instructions in the GitHub documentation for how to clone a repository.
pr/markdownToolbar branch of my repository (this is where development related to the toolbar is being done)On Linux, in a terminal,
cd /path/to/the/cloned/repository/git switch pr/markdownToolbargit pullBe sure you have the required dependencies!
Let me know! I can try to build an .apk file with the app and post it here!
Yes. Android tablet. It would be kind of you and appreciated to build an occasional .apk so I can join in the beta. I do spend 30-60 minutes a day in the Joplin android version either writing or reading what I've written.
Here's an APK:
Edit: Updated the APK version.
It looks like we're already using react-native-vector-icons, which packages FontAwesome (in addition to several other icon packs).
I've updated some of the icons:
Feel free to search for and suggest additional icons!
Where can I find the toolbar?I just discovered this version and am not familiar with it.
