Hi all —
I’m experimenting with Drafts widgets as a way to display reminders of weekly/quarterly goals, and would like them to show up as a nicely formatted numbered list. I have the widget displaying a particular Draft, but the numbered list doesn’t indent correctly because it is raw markdown instead of rendered. Is there a way to have the widget render its contents using Markdown or similar?
Thanks!
+1 on That request would be Great if the syntax of a draft could be reflected in the widget
How much of a draft would you expect to get rendered on a widget. Even a large one would be hard pressed to show much. And, unless iOS 15 brings big changes, I wouldn’t expect it to scroll.
(Not against; Just wondering how practical this would be.)
I think the most obvious use case here is drafts that just consist of lists, potentially short ones. There are a number of Drafts actions that make it easy to e.g. add a new item to the bottom of a list of ideas/movies/blog posts/etc. So I’d like to see that list displayed as a nicely-formatted ordered (numbered) or unordered (bullets) list in the widget. Could only be 2-3 items (e.g. my top 3 goals for the week)
I agree. That does sound like “special formatting” though…
… Suppose you have a draft with 5 items in a list and there is only space for 4. What do you want to have happen? It can’t scroll. It might be able to have ellipsis to indicate “there’s more”.
Even if we said “don’t make the list overflow and if it does we’ll just crop to fit the widget” there’s still how to render onto the widget.
My point is that quite a lot of parallel infrastructure would be needed.
+1 Here. I’ve been wanting this function for a long time.
I would think about it differently. Rather than a widget that needs to be an equivalent to the Drafts app UI itself, and thus be able to display any type of draft equally well, it is instead designed to only display small, short drafts. That puts the onus on the user to only pick small, short drafts to display, and if necessary, wordsmith the draft text to make it display better.
My main use cases are for things like:
Obviously the first time you read it you need to see the whole text. But in many cases, seeing the first part of the goals/reminders/QOTW/etc is enough to remind you of it and bring it to front of the mind. At that point, it has done its job, even if 100% of the text wasn’t visible.
That said, scrolling by dragging would be great, as would some sort of widget auto-resize if Apple enables that at some point. Giving a broader range of formatting options (font sizing, margins, option to hide the title) would also help. But for now, just having real Markdown formatting so the text formats, indents and flows correctly would be a great start.
The hazards here are twofold, to my eyes:
Hi Martin –
Definitely agree with #1, although that hazard exists today since unformatted Drafts get cut off if they are too long a/o the widget is too small.
Curious about your second one – what is “refused”? Do you mean if it fails to format due to malformed markdown or similar?
I mean if Drafts were to say “this is clearly too long to format well on a widget of this size”.
Technically, this is not really possible at the moment. Widgets are very limited. To render the output of Markdown as HTML, you have to use a web view, and they are not supported in Widgets, to the best of my understanding.
Widgets are designed to be very lightweight for battery use reasons, and things like web views (WKWebView) are not allowed - only native SwiftUI layouts that can be snapshotted by the system to be rendered at very low CPU cost.
Thank you for clarifying the technical limitations of widgets. Considering this, I propose a potential workaround: Drafts could render the Markdown text into a PNG image that aligns precisely with the device’s resolution. This image could then be displayed in a widget and updated whenever the text changes.
This approach would provide a highly convenient method for creating and maintaining a daily routine dashboard. To my knowledge, there are currently no other solutions that offer this level of flexibility. I believe this feature could significantly enhance user experience.
Creative thinking, but not also not viable on a technical level to get a rendering that would work well in a widget, I’m afraid.
Sorry I missed the point that if the process is fully automated, the rendering can only be run in widget’s limited environment.
Consider that, even require users to open Drafts iOS app to update the rendering is not only an acceptable but also convenient solution.