[Tex2002ans]

Originally Posted by KevinH

If you split out main title and its file-as, and author (and its file as), language (primary and secondary), and use a big box for description ... you really need two different tables to handle most of the rest:

There should at least be the 3 mandatory EPUB metadata:

• Title
• Author
• Language

I think these should stand out more prominently + NOT be deletable.

These 3 are also the most common use-case, so making these easy to find/read/adjust is a huge QoL improvement.

Originally Posted by KevinH

Alternatively we could stay with the current MetaEditor and try to replace all code pieces with translated names but keep the list with added extras approach, but try to do more to hide the code itself.

Yes.

Here's yet another example I just ran across.

I recently opened up Jellby's latest EPUB:

https://www.mobileread.com/forums/sh...d.php?t=335691

He made extensive use of metadata, but:

dc:contributor   Jellby
      opf:role   bkp
dc:creator       Ramón Cilla
      opf:role   ill

Off the top of your head, can you tell me what those 2 roles are?

While skimming through Add Property > Role... I'm assuming bkp = "Book Producer".

In that menu, names are human-readable, but no 3-letter code.

And in the main Metadata Editor, it's all 3-letter codes, but not human-readable.

Potential Enhancement #1

Making Add Property > Role a sortable 2-column format:

asg   Assignee
[...]
bkd   Book Designer
bkp   Book Producer
[...]
ill   Illustrator

(Sorted by 2nd column by default.)

Now that would be great. Then you could use it to find what you need OR an easy way to figure out what 3-letters = what.

I'm betting that would help even more in non-English, since Spanish might display:

bkp = Productor de libros

where English 3-letter-opf:role =/= foreign language spelled-out.

Imagine being a Spanish Sigil user, and trying to figure out what "bkp" stands for.

Potential Enhancement #2

Human-readable Metadata Editor.

Remove "code-speak" and replace with human language.

Current:

dc:title        Otros cuentos
dc:creator      José Fernández Bremón
  opf:file-as   
  opf:role      aut
dc:language     es
dc:contributor  Jellby
  opf:role      bkp
dc:creator      Ramón Cilla
  opf:role      ill

Potential:

Title           Otros cuentos
Creator         José Fernández Bremón
  File As   
  Role          Author
Language        Spanish
Contributor     Jellby
  Role          Book Producer
Creator         Ramón Cilla
  Role          Illustrator

I (ranted) about this back in 2017:

"Please, give us back old metadata tab!" (Post #24)

Other good info/ideas were buried in there.

And as I explained in that thread, the advanced code could still be there, just hidden under the surface.

When you double-click an entry to edit, perhaps the "real code" shows up:

• Double-clicking "Creator" -> "dc:creator".
• Double-clicking "File As" -> "opf:file-as".

Any sort of metadata that isn't normal, can still just display its code form.

Like in Jellby's EPUB, at the very end he has:

prince-style     pdfoutput_css

So even in the "human-readable editor", anything non-standard could still display straight code (just as it does now).

Originally Posted by KevinH

The other thing I do not understand is why people think the current MetaData editor is so bad?

A lot of these QoL adjustments not just help complete noobs, but also helps speed up advanced users.

Take Jellby's EPUB as an example.

Quick! What is the Language of this book?



Okay okay, you finally found it. But what about now?



Okay okay, you finally found it... But what about now?



Ahhh yes, Spanish. And it's right up top!

Oh, and those people were all Illustrators, I thought they were ill.

Side Note: Back in 2020, I wrote a little about (and linked to great videos) where a UX guy walked through an open source music program, MuseScore: Post #26, "Quick Question". He explains/shows how all these little niggles add up, and some minor QoL adjustments can really add up to help EVERYONE, at all skill levels, use the program more efficiently.

Originally Posted by KevinH

Perhaps time spent on improving and updating the User's manual should be of higher priority?

That may help as well, but not many people are helping on that front besides me.

And the ones that do write instructions/tutorial-type-stuff, tend to write too technical.

Perhaps still just focus where you're best, making Sigil better and better.

Originally Posted by KevinH

Comments? Thoughts? What level should Sigil really be targeting?

While yes, I think Sigil is an EPUB tool that's more towards intermediate/advanced, there's still a chunk of users that are just normal, non-technical authors.

Just a few days ago we had one wander into MobileRead:

"Sigil 1.4.3 - Validation Not Catching Errors Now"

Obviously she's not a complete "noob". She's used Sigil for many years, creating hundreds of EPUBs.

BUT she's not advanced/technical... just your typical author.

For that type of user, more simple, step-by-step instructions help. But not just her, they help ANYONE trying to use Sigil.

- - -

Let's say you wanted to validate your book, and you wanted to install FlightCrew:

Method #1:

Here you go:

https://github.com/Sigil-Ebook/flightcrew/releases
https://github.com/Sigil-Ebook/Sigil...idation-Plugin

Sigil Plugins: https://www.mobileread.com/forums/fo...play.php?f=268

Good luck.

Method #2:

Step-by-Step (with Pictures!):

https://www.mobileread.com/forums/sh...47#post4088447

Now, even someone who recently stumbled upon Sigil (or hasn't been following MR + all the Sigil threads for 5 years) could follow that.

Originally Posted by KevinH

Perhaps, a basic MetaData plugin would be best that just handles the simplest cases but that works for epub2 and epub3.

Maybe, maybe... but I think human-readable + splitting those 3 mandatory ones will be a HUGE step in the right direction!