Still, the formatting (apart from the colour) diverges a bit from the mock-ups and we could track that in this ticket.
Text format (font size, line height) should actually be the same (see mock-ups below).

If it is for the different colours, that is okay with me and complies to the mock-ups. The text is in the colour of the corresponding section (header section dark green, answer section white). The question mark icons are in different colours as well. In my opinion, that additionally underlines that the help text corresponds to either the question as a whole or a individual answer.

In general, it would also be nice to wrap text not around/below the checkboxes. I am not sure whether that is the case at the moment. See following mock-up ("Es ist kein Name/Pseudonym [...]"):

That sprite might be sufficient as there is need for a non-checked and hover state only since clicking advances to the next questionnaire step instantly.

Excuse me, that actually belongs to here:

Overlay of mock-up and implementation at the same viewport size:

No problem.

Two screens for the updated final stage. In both screens, the licence name is included in the heading "Ihr Lizenztext" and below the button "Vollständigen Lizenztext einsehen". However, I think mentioning it once is sufficient and I would prefer to have it placed below the button as the one in the heading will most likely just be skimmed over.

I have consolidated the visuals:

first raw draft:

Here is a screen with input box and checkbox:

OK, no problem. But do not feel urged to not combine progress bullet points not having shadows with checkboxes having shadows. I was just thinking that an overall "flat" look might be the one which is more desired/applicable as the input boxes do not have shadows as well (could, of course, apply some). And, all in all, the bullet points do not look that bad without shadows. Sorry, for making it complicated. ;) We can briefly talk about it on Monday.

Here are the updated screens (progress indicator inner shadows are removed in all screens):

Handling of other image formats:

1. "current final result"

Larger main navigation bar:

2nd iteration:

The following designs are for consideration.
Since Bootstrap is used, these were made with a template for MD size. Numbers correspond to pages in the wire frame document of T103979. Menu bar left out by intention.

Exported results of https://docs.google.com/presentation/d/1g01fV_DQcbwBIxb84Rvu1kXisM1dhbFoVH3TDmO5fcs/edit#slide=id.gc6540e1d7_0_0 for future reference:

• edit = Edit
• save = Check
• remove = Remove
• cancel = Would prefer Close over Cancel
• add = Add (May also be a new icon of "Edit" with a "+" sign (compare to "EditLock"))

We should not strive to invent icons different to the ones used in MediaWiki. Please have a look at those icons first:

• https://www.mediawiki.org/wiki/Design/WikiFont
• https://doc.wikimedia.org/oojs-ui/master/demos/#icons-mediawiki-vector-ltr

(I guess the latter one is "more current".)
I doubt it makes sense to design dedicated icons for "add [qualifier|reference|statement]". A generic "add" icon should be sufficient as long as it is ensured that the context can be identified by the user.

As per @Lydia_Pintscher's request:

Text entered into the text box should have the colour #636466. Might just want to add it to https://github.com/wmde/Lizenzverweisgenerator/pull/89. Thanks.

• Now that I know that the logo on Drive is different from that in the Wiki (where it is in square format): Please scale the logo to 80px height, making it a bit larger that it is right now.
• The text "Lizenzverweisgenerator" should be bold and the tagline's font size should be large enough to align in width with "Lizenzverweisgenerator".
• The attribution should be in italics.
• Please use German typographic quotation marks in attribution. The attribution text should be in German.
• The background image should be scaled that it always fills the viewport (like "background-size:cover;" does).
• The white space around the text box placeholder should have the same width/height (needs some more horizontal padding).

OK, now I get the picture! Although I wonder about the placeholders' use case if the information is not available instantly but after visiting a separate page first. The placeholder is basically mirroring the Wikidata page where it would be a good chance to make users directly aware of and get in touch with Wikidata which would be just one click away either. Of course Wikidata's major problem in that context is the UI but I wonder why not rather put some power into that.

OK, as the amount of text will be not too large, we may want to use lightboxes. Since the content of the lightboxes is not finalized yet, this is only conceptual again.
Some attributes that may not change though: header bar height: 42px with 30pt font size; background overlay is #dce4e8 at .8 opacity.

As for the menu items. I would not recommend opening those in a lightbox like it is done at the moment as that additional layer might contain another scrollbar. Instead, the content could just be appended to the main layout container and the viewport can be scrolled down automatically. Some exemplary screenshot:

I wonder whether you can get along with that:

Decision was made to go with green.

Is that heading into the right direction:

A few more / more detailed variations of the picture selection "page":

I noticed that we actually moved on from wire-framing as to the ticket title. I guess this ticket is actually resolved by your mock-ups, @KasiaWMDE, at https://popapp.in/w/projects/55b5224613c497de0dc28973/mockups/55d35c5d01823bd659e259e8 and there should be a separate ticket for actual design...

@KasiaWMDE: What is the status of this ticket? Can it be set to resolved?

@KasiaWMDE: What is the status of this ticket?

Is any additional change required or can the ticket be set to "resolved"?

Front page with magenta colour as per request:

We could just ask Google: https://cloud.google.com/translate/v2/using_rest?hl=en#detect-language
Well, no, but detecting a language is feasible. Just like for units, it is about making a proper "best guess" that is influenced by various parameters in addition to the actual input. Such a "best guess" could, of course, be altered (see T103835#1423985).

For clarification:
What information needs to be on the page except the data from Wikidata? / Is it that page that would basically be replaced: https://en.wikipedia.org/wiki/Page_that_does_not_exist? And there would be no redirection to full-text search anymore (https://en.wikipedia.org/w/index.php?search=Page+that+does+not+exist&title=Special%3ASearch&go=Go), provided a Wikidata item is found?

Reassessing that: As mentioned before regarding the basically wiped out unit selector discussion, still, the general idea should be to not require two input fields at all by having the software detect the unit from the combined string of value and unit. The (rest of the) procedure is described in T103835. The same would actually be possible for monolingual text by having the software detect the language.
Multilingual text is a value that very likely would require multiple inputs.

Dialogue supported version.

Basic version.

This should demonstrate the dialogue box concept:

Some first drafts (no pixel perfection etc.) for evaluation. Applying the WMDE colour scheme, apart from the green representing "legal matters", the software development blue could be used to make buttons stand out.

After some first evaluation, I still quite like the basic input concept offering as few input elements as possible and having the software make a best guess. This interface simplicity, however, has some implications. Those are, at least:

• The software needs proper logic for making best guesses.
• It is not obvious how some options may be set instantly, for example: uncertainty options like "before" and "lower bound". The question is, per option, whether it can be regarded primary or secondary. The term "advanced options" currently in use, probably, is not the right expression.
• The preview needs to be specific enough to make the user aware of additional adjustments (e.g. planetographic coordinates may probably need to display the globe unless there is some other concept that defines the globe, for example, per Property resulting in some Property like "position on Venus").
• Experienced users should be offered ways to enter information specific enough in order to circumvent false guesses (i.e. by entering something like "1 7 2015 Julian") in order to get around clicking through the secondary options.

Wouldn't those export options pretty much fit into the sidebar section of "Print/export"?
In general, I do not like the sidebar that much as it is a mix-up of global navigation and page specifics. However, it seems like a sensible place to put those options for now. As for the planned layout, there are multiple options I can think of for some first evaluation:

• There could be a dedicated section in the right sidebar (likely too prominent) or
• an "icon bar" at the bottom of the header section (either in the header section itself or just below) leaving the option to put additional functionality into such an icon bar. Maybe some toc pop-up listing all the properties applied to the Item - whatever.
• In the planned layout, the top right of the header section would feature an "edit" icon with a drop-down list attached--that might be a place to put that as well instead of putting additional--probably rather specialized--content/links into the page directly.
• Another option would be to have an unobtrusive icon bar above the header / rendered Entity contents with icons aligned to the right shifting all of the rendered Entity a couple of pixels down. This might even more express the Entity (page) wide nature of the actions aggregated there. Having just one icon that makes a box pop up when clicked is a sensible solution of course.

• No proper copy-pasting which is a big disadvantage for things like such.
• It is quite natural to type a string that contains value and unit. Two input elements instead of where one would be natural is irritating. Placeholders would ease the situation a bit, but the need to tab between inputs for something that is normally typed in one go is kind of awkward.
• Being aware about form/page navigation using the TAB button involves a certain degree of expertise.
• Contradicting to natural position of some units, e.g. $10 vs. 10$.

Some first draft. May need some more annotation, but should be sufficient for a first review:

The attached wireframes are just about basic layout.

• "Important Notes" container may change its height. Hence, that container should be vertically flexible without shifting any other container's position. (Nothing should be below that container.)
• The image would always be centered vertically in the browser's viewport (scrolling...).
• Not overwhelmed by the idea of aligning the image to the right as alignment of text block would be in disorder and important interaction is pushed too far off the center. The center is a more comfortable place for the eye to rest as one can monitor changes on the screen more easily, keeping in mind that this software has multiple stages instead of being one static page.

Some first version. Please review. Ironically, the prototype only runs with JS.

Here's some suggestion being aware of the implementation should not be overly sophisticated.

As of T96679, control on the diagrams is out of my hands and I will not touch that diagrams again without clear responsibilities being established. (Pointing on T92365 once again...)