Improving consistency and accessibility between TabularInline and StackedInline.

[Antoliny0919]

The biggest difference between TabularInline and StackedInline is the direction in which the fields are arranged(row or column).

Currently, TabularInline and StackedInline seem to clearly showcase their differences.
However, I don’t think there should be any difference regarding the __str__ of the Form objects inside TabularInline and StackedInline.

As shown in the image above, TabularInline only displays the object’s __str__, while StackedInline adds the model name and a colon as a prefix to the object’s __str__. (Additionally, the font size in TabularInline is very small, and there is a noticeable font size difference compared to StackedInline. Furthermore, the font size of the fields also changes when the screen resize.)

As mentioned above, TabularInline and StackedInline already effectively represent their unique characteristics through the arrangement of fields, so I don’t understand the difference in the object(str) related parts. I believe these should be made uniform to improve consistency between the Inlines.

Additionally, when the show_change_link attribute is set to True to add a link in the inline, the background image in TabularInline gets slightly cut off at the bottom.

I think it would be better if the show_change_link attribute were set to True by default. Also, when the show_change_link attribute is set to True, I feel that the background image and text(Change or View) that appear are unnecessary. This is because the form already effectively represents these characteristics.

I have applied the link to the object’s __str__ as shown in the example above. However, when making changes like this, additional handling may be needed if the __str__ is empty or contains something like “-”.

To summarize the points so far, I believe there needs to be consistency in the object __str__ section for TabularInline and StackedInline. By setting the default value of the show_change_link attribute to True and making the link more streamlined, accessibility can be improved, and it will look cleaner as well.

I have already created an issue regarding this and feel that further discussion is needed.
(I would appreciate feedback or thoughts from others on these proposed changes.)

Issue

• Cleanup the inline link format.
• Size of the object’s str in TabularInline is too small

[Antoliny0919]

I have implemented the improvements I had in mind into the InlineForm
InlineForm header new feature.

In addition, further steps are needed, such as adjusting the position of the “x” button and handling cases where the string used as a link is empty.
Still, I believe the changes above are enough to show the InlineForm header as I envision it.

I can relate to many aspects of why the current Inline design was implemented.
I had wondered why the text of the object’s str used in the Form Header of TabularInline is small.

However, since TabularInline represents fields in rows, the height of the Form within TabularInline is not large, so there’s no need for the object’s str text to be large.
(Nevertheless, I still feel that the current text size is too small.)

On the other hand, StackedInline represents fields in columns, and as the number of fields increases, the height of each Form grows as well.
In this case, the object’s str serves as a separator between the Forms.
Therefore, I understand that the object’s str is displayed larger and that the model name was added to the suffix.

The reason I made the TabularInline header the same as the StackedInline header is because I felt that the StackedInline header provides better UX
(of course, adjustments to the font size and padding are needed).

This is because, just like in StackedInline, the height of the page in TabularInline also increases as the number of objects grows. Ultimately, whether it’s TabularInline or StackedInline, I believe the current StackedInline header is better when there are many objects.

However, the StackedInline header doesn’t feel out of place when there are fewer objects either.

The reason I added a link to the object string itself is that I thought this approach was much cleaner. I felt that there was no need to display text like “View” or “Change” — adding a link directly to the string itself is intuitive enough.
(However, it is important to clearly distinguish it from the “View on Site” link that appears when the show_url attribute is True.)

I’m curious to know what others think about the InlineForm Header. I’d love to discuss it more and I feel there is room for improvement.

[CodenameTim]

Generally speaking, as another Django dev, I really like seeing these changes. I’ve run into your original concerns about labels missing or being inconsistent and I never understood why it felt “off”. Now it makes sense.

[sarahboyce]

I believe there is a few suggestions here:

1. Align the StackedInline and TabularInline titles, with the suggestion to use the StackedInline title format (model name : object string method)
2. Change the default of show_change_link to True
3. Remove the “View” and “Change” icon/links and instead have the object string text a link

On 1, I am +1. Though I have no real preference between the Tabular vs Stacked approach
On 2, I am -1. This is a change in the default behavior and if folks are happy with their setup (disallowing links by default) then they would need to make quite a bit of changes. I would like to see a community discussion/agreement to change the default.
On 3, I am -0. I prefer the design suggestion but it isn’t limited to just inlines (there are other widgets with similar approaches). We also have “issues” with blank text which makes the links not clickable with this change. We would need to be consistent.

It would be nice to have other folks to state their opinions also.

[Antoliny0919]

Thank you for sharing your opinion.
I feel that even achieving just point 1 would be a significant improvement. The main issue that bothered me was the inconsistency in object titles between Stacked and Tabular. Personally, I prefer the Stacked title format.

As mentioned in the main text, Stacked inlines are more likely to have greater height, so including the model name in the title improves the UX. Of course, I don’t think it would be a problem if this approach were applied to Tabular as well.

[tom]

I am +1 for at least changing the titles. My preference would be to remove the object name from both rather than adding them to both as it seems redundant to the heading above but I think either is better than not doing anything.