Nostr

I'd like some design feedback on Alexandria.

I'm working on an article editor feature. A screenshot of an early draft is below. The overall goal is to be able to type AsciiDoc-formatted text, preview it in rich text form as it would appear in the Alexandria reader view, then publish it as a cluster of kind 30040 and 30041 events.

My thinking is to break the content down into sections. The content of each section will be published as a kind 30041 note. Each section will be indexed by a kind 30040 note, which will reference the content of the section as a kind 30041 and any subsections as 30040 notes.

Question: How would you like to preview your published events?

I see two options:

1. There are two preview steps: one is a "quick preview" you can see with a click while editing. It doesn't break the content down into 30040 and 30041 events, but it shows you what the nicely-formatted AsciiDoc content would look like. The second preview steps shows the content as it would appear in reader view, after it's been broken down into its constituent 30040 and 30041 events. This preview would have a confirmation dialogue that lets you approve or cancel publishing the events.

2. There's just one preview, and clicking the preview button while editing shows you the content as it would appear in reader view, broken down into 30040 and 30041 events. There would be no separate screen with a confirmation dialogue, and a publish button on the editor page would publish the events.

I'd love to hear people's thoughts!

#asknostr #alexandria #gitcitadel #nostrdev #nostrdesign

Laeserin 1y ago

Title field is mandatory. Author is optional, even though it'll probably be added for books. Not really clear from the interface.

Maybe add a red star next to "Title", or something, or demote author into the Asciidoc header.

Reply to this note

Please Login to reply.

Discussion

MichaelJ 1y ago

The UX rule of thumb I've heard is "Don't punish the user before they've performed an action."

So best practice is to make optional fields optionally visible, and not to show the red stars and such oj mandatory fields unless the user tries to submit the form without filling out all the necessary fields.

Laeserin 1y ago

So, move author into ascii? Most 30040s won't be cohesive documents, like an original book, but rather someone's personal compilation of documents or snippets. A sort of remix. They won't have an author, but the 30041s might and they'd probably have author in the ascii or the form would get really messy.

Right now, these are the mandatory tags (we need "d" and we need "title" to make "d"):

[ "d", "" ],

[ "title", "" ]

And these are the optional ones:

[ "author", "" ],

[ "i", "isbn:9780765382030" ],

[ "t", ""],

[ "published_on", "" ],

[ "published_by", ""],

[ "image", "" ],

[ "summary", "" ],

[ "version", "" ]

MichaelJ 1y ago

Pulling author from the AsciiDoc would be good. We could even have a prompt before sending to ask if the user wants to use whatever author name we found in the content.

Laeserin 1y ago

Yeah, I saw the title and author lines in the asciidoc header and got confused because there's also a field. Maybe generally have a metadata section at the top of the preview, with the asciidoc header info pulled, for them to edit.

And then we have it prepared for generating ePUB format. We just have to map to the require ePUB fields.

https://docs.asciidoctor.org/epub3-converter/latest/

Laeserin 1y ago

I didn't even think of the fact that Asciidoc can already have a bunch of the metadata we can process defined as header fields. 🤔 We should probably map-n-pull that into our json tags.

https://docs.asciidoctor.org/asciidoc/latest/document/header-ref/

Laeserin 1y ago

There will be more optional ones, in the future, depending upon the type of data in the linked events. Like, we'd need "director" for a movie snippet.

Laeserin 1y ago

The metadata fields are the same, for 30040 and 30041. It's just that the latter contains content and the former contains a list of events.