1. Looks outdated and uninviting. Not like the big feature it is.
2. Uses live table, not live data (I know this is in process of being updated)
3. App Within Minutes is not a very good name for this feature. It implies something along the lines of no-code app building. This is really what I thought it would do when I started out in XWiki. While, of course, it can be used in that sense, it's main purpose it's to store structured data in a format that's easily actionable (filterable, sortable, searchable, refferenceable)

These issues concern all the steps:

1. Progress Bar states not clear. The current step is green, but the blue ones look much more important than it, which makes a bit unclear along the way where the user is in the creation process.
2. Next step and previos step are too far apart. Distance between targets increases effort (related to Fitt's Law)
3. Strips of light gray make the UI feel fractured, thus building clutter
4. Uses silk icons. They look outdated

1. The explanation in the right is unnecessary. The steps are presented pretty well and concise in the progress bar. No need to overwhelm the user with too much information from the beginning. Let's stick to presenting it in chunks.
2. No need to explain how the title of the application affects the link and location. The user will put the name they find most fitting for their data and afterwards reconfigure the location if they don't want the default. The idea is to make this process simple easy for a new user, let's take out things that can be understood later or from the context.
3. The complete link and path are not very interesting for a new user, they can be collapsed or hidden. This is to continue the process of simplification.

1. Drag and drop is not necessary here, it feels gimmicky, implying more effort than it should. This effort is created by the distance between targets (related to Fitts' Law) and repeated long movements of the mouse to achieve the task of adding a new field. It also implies a slight learning curve even though it's explained in the UI. Most software doesn't use drag and drop for creating new fields/columns, but only for moving them. Creation is done by single clicks.
2. Description of how to add fields is duplicated. No need to clutter with the same info.
3. Field types are not self-explainable or don't explain use case context. A new user of XWiki can be confused fields like Static List, Content, Title, Database List.
   • Static List implies understanding the concept of static and dynamic and also the difference between this field and Database List.
   • Content can sound confusing if you don't know already that every entry/record in an application/collection has a page associated to it.
   • Same with Title.
   • Database List is very confusing. It can imply to a technical user the idea of relational databases, but even that isn't sure.
4. Field categories are not very clear or cohesive.
   • Pickers describes what kind of UI may be needed to interact with those kinds of fields,
   • Standard implies basic functionality but doesn't include Date, which would be highly expected to be a standard field
   • Page is confusing because it doesn't explain the idea of an entry/record having an associated page to it,
   • Advanced aliens new users even though Database Lists are very powerful fields.
5. In this current step, the user doesn't know about generic columns that are presented in Step 4. The problem is that a user accostomed to no-code app builders or other software that has database builders may think he needs to add fields like the ones that are generic in XWiki, causing functionality duplication and, thus, the need to go back from Step 4 to Step 2 to delete useless fields. If he doesn't delete them, then he'll miss out on automated processes that make the applications/collections great in XWiki

User gets to Step 2

6. Before selecting the field, it doesn't seem moveable, editable or deleteable.

7. It is not intuitive at all that the label of the field is clickable and is an input field. It took me a few tries before giving it a try and clicking on the label itself. I was very surprised that it actually worked

8. Hint input is very confusing, making this very important feature seem useless

• Its label doesn't explain its functionality
• It doesn't have a placeholder text that could explain it.
• The tooltip (Default value) seems to say that the null value or the empty field value is the default value, not that whatever the user inputs will become the default value for that field for a new entry.

9. Inputs don't have a placeholder texts, which makes them feel bugged or confusing

User adds field and selects it.

10. Everything related to the Database List field is confusing

User added multiple fields and wants to add a hint to a Database List field.

1. The information about entries being pages needed to be in Step 2
2. Choosing an icon takes too much space in the UI
3. The icon chosen for the entry is not showcased, just named
4. The fields in this step need to be grouped a bit better, it seems all over the place.
   • Especially the fields related to the paths/locations should've been one near the other one. I needed to look twice at them to realize they are NOT saying the same thing.
5. There is no need to explain Icon and Description (they could be named General Entry Icon and General Entry Description). Their explanations clutters the UI for the sake of cohesiveness.
6. The decision of having the pages terminal or not may slow down the process for new users which may not now which is the best choice for them. Even for users acostomed to XWiki, it is possible to not predict certain future needs of a application/collection from its start. This option should only be available in the edit mode of the aplication/collection, not in the creation process.
7. The terminal pages option ocuppies too much space for a binary field
8. The option "Don't enforce entry location" could be reformulated to include the explanation, to escape clutter

 User gets to Step 3

1. There is no need to have a big explanation of application title and description. Their labels can be reformulated to include the explanation. The explanations occupy valuable space.
2. The explanations in the right side related to the generic columns seem to regard the Title and description based on proximity (Gestalt's law of proximity). This info needs to be closer to the part in which the user sets the live table columns.
3. The dropdown for live table columns doesn't have a placeholder text that explains what the user chooses.

User gets to Step 4

4. The live table columns dropdown is not consistent with other dropdowns in XS

5. The default live table columns don't include the user defined fields, the user needs to add them (again), which is annoying. The default ones are some of the generic ones, not even all of them.

6. Not all generic columns are explained

7. The icon chosen for the application is not showcased

User opens live table columns dropdown

1. The page doesn't seem to have true structure. The Entries heading is far up from the tables. The Actions group occupies a lot of vertical space.
2. The Actions group isn't cohesive with the rest of XS.
3. The description should ocuppy 100% of width of the main container. If the description of the application can be highly edited and beautified then it should strech on the whole space horizontally.

User is on his application homepage

4. The entry addition modal has an input with no placeholder text.

5. Entry name isn't any of the fields that the user defined and isn't exactly named like one of the generic fields it seems to be (Page title or Page Name). There has to be a cohesiveness between them.

6. The creation of the entry needs to be a 1 step process, no need for a name modal and then a page for setting the values for the fields. It makes the addition process slow.

User clicks Add new entry and a modal opens

7. The new entry has no general description even though in Step 3 the user provides a general description. This is important because it makes sure the creator of the entry understands the context of the collection properly.

8. No default hint/no placeholder text for inputs (what if the creator didn't add a hint? there's no placeholder text?)

User gets to the new entry form

add back the add field button

1. The idea is to let the user create structured collections of data very quickly, the same way he would do it in other software, but with the possibility to dwelve into more configurations (configurations that other software might not have) if need be. Thus, we hide steps 3 and 4 behing a collapseble heading (Additional Configuration) and seemingly merge step 1 and 2. There is no need to number steps and make the process seem too long. Step 3 and 4 were there to change defaults into customs, not create something new. Without step 3 and 4, the user can still very much use the collection, it's just that they would may make his life easier in some cases.

2. Because we base everything around live data, step 2 is remade as an initially almost empty table with only one example column given (Name, which is a short text field, identifyable by its icon).

3. The explicit blue text makes it clear to the user what he needs to press in order to add a hint text to the column (Enter search hint...) or add a new column/field (Add new field...).

4. Their intent is also supported by the iconography: search hint is accompanied by a search icon and the additon of a field is accompanied by a plus icon. This style of buttons is cohesive with other revamped areas of the UI, like the addition of tags.

5. This whole process is explained concisely in the beginning, specifying also the fact that the user can add entries only after he defines the collection, unlike other software. Explaining this to the user may alleviate possible frustration with the fact that live data doesn't work like Notion's databases or other software's collections.

User creates new collection and is led to a creation page

add another frame before this that makes it easier to understand the dropdown

add another frame after this that makes it easier to see the visibility property

add another frame after this with hidden field

After setting the search hint, the hint turns gray.

When clicking on the Add new field button, a modal extends downwards.

This modal/dropdown containes 3 input fields:

• Field name,
• Search hint (with an info icon that, on hiverm explains what is this for)
• a Field type dropdown that extended doesn't create another modal just lists all types downwards
• Visibility setting - this specifies if the property will be shown in the live data table (visible) or seperately (hidden)

User decides to add a new field (add another frame before this that makes it easier to understand the dropdown)

When clicking outside of the dropdown, it closes and the field is defined

When hovering over an existing field, its cell changes:

• it gets a light gray background,
• the left and/or right borders get wider and blue
• the move icon appears and is blue, in the left side of the field icon
• the edit icon appears and is blue, in the right side of the field name

User hovers on one field

User extends additional configuration

1. The progress bar has been extended horizontally to correctly vizualize the moderately lengthy process. Steps are connected with a line to increase the idea of journey or steps or process.

2. The progress bar states are better illustrated, with a clear focus on the current step

3. Labels of input fields are in Sentence case everywhere. CHECK THIS

4. All input fields have placeholder text

5. Non-essential details/explanations/examples are collapsed by default

6. Keeps Next step and Previous Step close to one another (related to Fitt's law)

7. Next step and Previous step buttons have chevrons that indicate visually the direction in which the process is moving

Come back on the mockup and change application into collection

1. We explain the concept of collection and records to the user and guide him through the process: Your data is stored as individual records in a collection. let's define this collection.

2. There is a placeholder text for the input field

3. Link and Code of the collection are collapsed. they are not essential information for a beginner user. Not processing their info speeds up the creation process

4. The user can't go to the next step without filling the name

User starts the collection creation process - Step 1

1. The user decides on what field he wants first and then its type.

Anyone that wants to use Collections understands the idea of "fields characterizing data". So we simulate the thought process that anyone has when adding these fields/columns: What fields bext characterize your data?

This approach transforms the thinking of "what data type should I add first? is this type best for this or this other one?" into "what data fields does my data need to have?"

The benefit to this transformation is that a non-technical user 100% knows the fields he needs even if he is not sure of all the data types he could use, making the process more natural and familiar ( in excel sheets/spreadsheets, you name your columns and then decide what you do with them)

2. To add a new field, the user just clicks the Add new field button

User gets to Step 2

Come back on the mockup and change Data type into Field type

Come back on the mockup and add back the move option

Come back on the mockup and add back hint

3. A new field has the label New field (Undefined)

4. Any field has a icon in front of it based on its type. A new field has a star.

5. The field is characterized by name, type and a hint.

6. The field type can be selected from a dropdown.

7. When the field is extended, it is in edit mode and it can be edited, deleted or reordered.

User adds a new field. The field is currently undefined

Come back on the mockup and change Data type into Field type

Come back on the mockup and add back the move option

Come back on the mockup and add back hint

8. If the user needs more details, that info sits in the right side collapsed. On click on any of them, it extends downwards

9. In step 2, these extra details are

• examples of fields and types
• explanation of default fields (formally known as generic fields) and awareness of their existence

User extends the info in the right for examples and explanations

Come back on the mockup and change Data type into Field type

Come back on the mockup and add back the move option

Come back on the mockup and add back hint

10. The field type can be selected from a dropdown that is organized in the following subcategories which are named based on their function:

• Standard types
  • Short text, Long text, Number, Date, Boolean, Static List
• Types related to a record's page
  • Page Content, Page title
• Connector types
  • Page, User, Group
• Relational types
  • Database List

11. Each field type from these sub-categories has a specific icon that, if chosen, will become the icon of the field.

12. Each field type from these sub-categories has a info icon in blue.

User open the data type dropdown

Come back on the mockup and change Data type into Field type

Come back on the mockup and add back the move option

Come back on the mockup and add back hint

13. When clicked, the info icon extends an explanation of the type and maybe gives an example of usage. The icon becomes gray while the explanation is extended. If the icon is clicked again it collapses the explanation. I opted for a info icon and not for a chevron because I don't want to make the user think there are sub-categories in the subcategories of the category, it has to be clear that those are explanations and not proof of another level of complexity.

User clicks on the info icon for more explanations on a data type

Come back on the mockup and change Data type into Field type

Come back on the mockup and add back the move option

Come back on the mockup and add back hint

14. Once the user chose a name and a type for his field, it stops being undefined and New field takes the name and the star icon transforms into the type icon.

15. The Next step button becomes blue, indicating the user that he can proceed to the next step if he wants

User defines the field he created

Come back on the mockup and change Data type into Field type

Come back on the mockup and turn chevron

Come back on the mockup and add back hint

16. When another field is added the previous one that was extended gets collapsed and its chevron gets turned to the left.

User creates another field. The previous field shrinks

Come back on the mockup and change Data type into Field type

Come back on the mockup and turn chevron

Come back on the mockup and add back hint

Look of interface after having multiple fields defined

1. We build some structure in step 3 by dividing all the info needed in 2:

• Locate based on path in wiki
  • this is where we have the entry point and end point
• Locate visually & based on content
  • this is where set the default record icon and a general redord description

2. Entry point is the new name for "where you add the record from". End point is the new name for "where you add the records". The latter explanation was reformulated as "where you store the records". I didn't want to use the verb add in both cases, as it is currently, because people scan the text and may not read the last word ("from" or nothing or "to") which makes the fields seem like they do the same thing.

3. For binary input fields we can use a toggle or a checkbox. I used a toggl but a checkbox would've worked as good.

4. Limit the descriptions of the fields. If they are named well and have a small explanation we don't have to right 2 rows of text for them.

5. In the "Locate visually & based on context" we have the icon field ocuppy less space and make a special dropdown. The user only wants to see the icon, not its name, I believe. If nothing is selected we'll have the question mark as the default value of the icon. If an icon was selected, that icon will be displayed in the circle.

User gets to Step 3

User open record icon dropdown

Come back on the mockup and include by default at viewable fields most popular generic fields + reverse colors

Come back on the mockup and fix: Set up your collection's homepage

1. In this step, we should enable the description to strech on 100% of the page for easy page customization. This should be reflected in the homepage itself

2. We renamed other inputs are moved them after the description, to not limit the description space

3. We made the viewable fields / table columns  in the style of the revamped tags with the default columns in white and the user defined ones in light blue.

4. All user defined fields and all default fields are already included. The user can delete the ones he doesn't need very quickly

5. It would be nice if we included a preview of the collection homepage so the user can edit stuff in the description or in the field naming before finishing

6. In version 1 (the one in the irght), the homepage preview orders content in the following order:

• description
• actions - introduced by the heading Actions
• live data table - introduced by the heading all records

More details at the Collection Homepage analysis

Version 1

Come back on the mockup and include by default at viewable fields most popular generic fields + reverse colors

Come back on the mockup and fix: Set up your collection's homepage

7. In version 2 of the preview, th structure of the homepage is:

• description
• live data table - introduced by the All records heading, contains all actions represented by only icons on the same row with the heading

Version 2

1. The look of the homepage is much cleaner , more structured.

2. The description is empty by default (the heading and the lorem ipsum don't exist)

3. Actions ocuppy less space vertically and are cohesive with other parts of the UI

4. Live Data Table is slightly improved (more detailed in the Live Data Minimal Revamp)

User is on the homepage of this collection (V1)

This is version 2 of the homepage revamp

3. Actions ocuppy less space vertically and are cohesive with other parts of the UI. They don't have a text besides the icon and that makes it easier to put them near the live data table, in a very minimal esthetic. This may hurt accessibility slightly, but their tooltips will explain everything needed.

User is on the homepage of this collection (V2)

Include the page name edit field

5. When the user clicks on the + Add record action, no modal appears. The user is directly lead to a page which is by default named by the formula: Collection name + Index in collection.

6. The record can be renamed in the creation form

7. Every newly created record features the general description the creator of the collection set up for giving context to every record in general.

8. Every field has an icon in front of its label to specify the field type

9. Every field has a default placeholder text even if the creator of the collection didn't provide a hint

10. The length of the input field depends on the field type, thus having 3 lengths on desktop: 1/3 out of the whole row, 1/2 of the whole row, the while row

11. In the creation process of a new record there should list the possibility of adding formated content. Is there already? I've added as a new field name Page Content, but maybe it's not needed. If there exists the possibility, then that tye of field should have an editor attached to it for easy customization,  not relying solely on markdown syntax

12. After all of the fields, we could move the Add summary field (currently on the bar with the save and cance buttons) to improve discoverability of this important feature and also to update the general description of the record. Whatever the user inputs here (if he inputs) becoms the updated description of the record. I think this idea would also imply the creation of another default field / generic field: record summary.

User add new record

1. We give the possibility to the user to see one record's data as it would be isolated in the table, on one row. This makes following data easier sometimes because it's closer together so our eyes can follow it more easily. This is especially important when trying to analyze data that you cannot remember easily (big numbers, names outside of your country, etc.)

2. The normal format (vertical listing) is kept too, respecting the style from the edit/creation mode. The onyl modification we should do is keeping the field content inline with the field label for fields that not require more 100 characters (short text, date, emails, pages, group, user)

3. We list the summary at the beginning of the page

User views a record

1. There are no placeholder texts for search input fields and no iconograhy to indicate better the type of inout there is (UI has to be predictable, not a guess)
2. There is a weird seemingly unitentional spacing on the header titles because there is left space for the move icon
3. The input fields for search look a bit out of place where they are right now

1. We eliminate the rectangle with rounded borders around the search input, integrating the search seamlessly in the table
2. Every cell has some borders
3. We clearly add placeholder text (we can default text for every type of field) and proper iconography.
4. For fields that are not numbers or long texts, their content should be aligned horizontally on the the center.
5. Long texts fields should be alligned to the left in LTR languages and to the right in RTL languages.
6. Number fields should be aligned to the right if we can make sure that all numbers have the amount of decimals (it helps the user quickly define the higher or lower values). Otherwise, number should be alligned on center.
7. All fields should be alligned vertically on the middle, making it easier for the eye to follow the whole line.