# 更好地处理包含大量内容（大列表）的站点设置
**URL:** https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042
**Category:** Feature
**Created:** [2018 年6 月 17 日 01:08 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042 "2018-06-17T01:08:09Z")
**Posts on this page:** 20
**Page:** 1
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 17 日 01:08 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/1 "2018-06-17T01:08:09Z")
Hi! I’m adding this topic to talk about improvements that might be made to how large lists are handled in settings.
Continuing the discussion from [Discourse Version 2.1](https://meta.discourse.org/t/discourse-version-2-1/86339):
> [@Discourse Version 2.1](https://meta.discourse.org/t/discourse-version-2-1/86339/1):
>
> - Better handling of site settings with large amount of content (big lists). See [Linkify words in post](https://meta.discourse.org/t/linkify-words-in-post/82193/38)
It seems like it boils down to three issues:
- scroll-position-jumpiness on adding or removing list items makes it difficult to know what happened and stay oriented
- long values are difficult to view
- lack of feedback on saving makes it easy to click the reset button and lose content
It looks like a good solution to these problems was proposed here:
> [@Auto-Linkify Words](https://meta.discourse.org/t/linkify-words-in-post/82193/20):
>
> Here is my proposal: A new site-setting type: dictionary. one item per row explicitly shows the key/value relation ellipsis the end of the value so it’s always readable will limit the height for the component so it becomes scrollable after something like 10 rows If it works for you I will work on it beginning next week.
> [@Auto-Linkify Words](https://meta.discourse.org/t/linkify-words-in-post/82193/25):
>
> After a discussion with sam: rename our current “list” to “compact-list”, which will display as many items per row it can (list current behavior) “list” will now only display one item per row this shouldn’t touch server side client setting, default UI for list will be modified, and the new client side site setting “compact-list” will rely on “list”
…which resolves everything except the issue of accidentally resetting the content by trying to click the “save” button multiple times; one solution to that problem might be to immediately replace the save button with a spinner after a click.
As far as I can tell this project isn’t already in the works, is that right? Does this strike everyone as the best solution?
---
### 作者：  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### 发布日期： [2018 年6 月 17 日 12:16 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/2 "2018-06-17T12:16:15Z")
Yes I will tackle this for 2.1, as said in the other post it’s definitely at the top of my list, I want to work on few things concerning the dashboard first and I will come to this then.
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 17 日 13:34 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/3 "2018-06-17T13:34:10Z")
Ok, sounds great. Thank you!
---
### 作者：  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### 发布日期： [2018 年6 月 17 日 20:52 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/7 "2018-06-17T20:52:11Z")
I took the opportunity of your post to think more about it and give a more detailed answer to your question.
I do agree your solution could solve it. We would have to decide what is a good “grace period” for this spinner though. Something which would avoid fast click but don’t bother users, 1s ? I’m also a little bit concerned, that it would make the UI feels a little bit slow. So we would have to try it and see how it feels. Any other idea I have so far would involve to move the save button at another place, and this is not ideal as it would just make things slower for the critical path.
I would also want to add another new issue to this nice recap: very long urls. ATM if we have a very long URL it will either overflow the container and be hidden (making it impossible to click on the or we would have to display it on multiple rows, making it very ugly. The simplest solution I see here is to move the to the beginning. So I might make this change globally to any select-kit input. Another solution would be to make the text fade out and have the over at the end, but this would be quite complicated when the other solution is so easy. Do you have another idea on this?
---
### 作者：  [@sam](https://meta.discourse.org/u/sam)
#### 发布日期： [2018 年6 月 17 日 21:37 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/8 "2018-06-17T21:37:24Z")
Sorry Jay,
We would still be more than happy for you to build this provided you follow @j.jaffeux guidance as he built the original control and select kit library.
I think the best next step here would be some visual mockups, I think even hand drawn is fine if that is the way you roll 😉 then once we are comfortable with how the UI will look we can move ahead and do the code part.
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 17 日 23:13 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/9 "2018-06-17T23:13:47Z")
Regarding the spinner, I think you’re right to worry about making it too slow – I’d think less than a second might be good, maybe even half a second? In addition to preventing accidental double-clicks, it can help give the user an indication that something was committed; currently it’s _so_ fast that it if you were unsure of which button you clicked you might wonder if it was saved or dismissed. I’ll mock up a few variations and post them here to see if a spinner & very short delay makes you happy or sad.
Regarding the `x` vs. long urls, I can’t think of a better solution using this control than your idea to move the `x` to the beginning… I think that would work great. Ultimately maybe long lists of key-value pairs call for a purpose-built control, but I’m guessing that’s out of scope for this project? In any case I’ll follow @sam’s direction and put a couple of sketches together to see what you think.
Thanks again for your help.
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 20 日 15:10 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/10 "2018-06-20T15:10:18Z")
I put together a mockup of what a spinner animation might look like:
> **[Edit fiddle - JSFiddle - Code Playground](https://jsfiddle.net/cidermill/0mxd5g14/)**
>
> JSFiddle - Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle.
The markup, scripts, and styles are rudimentary here and not meant to represent how it would be implemented, but I hope it gives a sense of the idea and it would let us play with the delay, etc.
This may or may not be what you’re after here – please don’t hesitate to let me know if you’ve got something altogether different in mind, and I’d be happy to try to sketch it out. In the meantime I’ll take a look at a draft of an option for what the field itself might look like with the changes you proposed.
---
### 作者：  [@riking](https://meta.discourse.org/u/riking)
#### 发布日期： [2018 年6 月 20 日 17:23 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/11 "2018-06-20T17:23:45Z")
I’m not sure we need to spend quite that much time on the animation here. (1) it’s an admin-only area, (2) you’re going to need a no-animation version for accessibility, (3) that’s a lot of moving parts.
How about simply disabling the reset button for ~2seconds after the confirm comes back from the server?
* * *
Also don’t forget what this topic is primarily about – improving the “list” data type. The reset button will help with every setting 🙂
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 20 日 17:35 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/12 "2018-06-20T17:35:13Z")
Fair points. I’ll mock up a simpler alternative for comparison.
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 22 日 04:50 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/13 "2018-06-22T04:50:34Z")
Here’s a version of what the `list` might look like with:
- `[x]` at the beginning
- key/value indicator in place of a comma
- one item per row
or a [gif](https://www.dropbox.com/s/t9gtrzccawjnj7n/2018-06-21-093029.gif?dl=0) if it’s helpful.
@j.jaffeux, you mentioned adding ellipses (shown in your [screenshot](https://global.discourse-cdn.com/meta/original/3X/5/4/5423ad08d7ccefca50ad4341dc84c83743b394fb.png)); those aren’t included here but I’ll add them if you think it makes it more clear.
Does this (plus disabling the reset button) more or less give us what we’re after? I still think there would be some value to showing a spinner on clicking ‘save’; maybe simply [replacing the checkmark with a cog](https://d.pr/i/JXkk8c), with no other animations, would be easy enough to implement without adding complexity.
---
### 作者：  [@sam](https://meta.discourse.org/u/sam)
#### 发布日期： [2018 年6 月 22 日 05:15 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/14 "2018-06-22T05:15:49Z")
This looks good, can you scroll sideways to to see the full text?
How doe the UI look for adding pairs?
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 22 日 06:13 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/15 "2018-06-22T06:13:58Z")
Here’s one way side-scrolling could work:
Currently adding key/value pairs works the same as it does in the current list control ([gif](https://www.dropbox.com/s/69utpsv29oz2ztn/2018-06-21-adding-values.gif?dl=0)). If it’s not clear, I’m faking the arrows for these screenshots by adding them to the text before I paste it into the field.
The idea is that in practice you’d paste `key,value|key,value` just like before, except here we’d convert the delimiter to arrows after the paste. If it’s in the scope of this project I’d be happy to work on ideas for improving the way we add items to the list (or to work on your idea if you already have a plan).
---
### 作者：  [@sam](https://meta.discourse.org/u/sam)
#### 发布日期： [2018 年6 月 22 日 06:35 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/16 "2018-06-22T06:35:40Z")
This feels pretty high friction to me, especially the adding part, I wonder if simply extending this makes more sense:
This control feels way more natural as a way for dealing with these lists.
---
### 作者：  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### 发布日期： [2018 年6 月 22 日 07:50 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/17 "2018-06-22T07:50:05Z")
Aesthetically speaking, having the entire line be a button is not ideal, so I’d go with @sam’s idea.
---
### 作者：  [@Jay\_Jansheski](https://meta.discourse.org/u/Jay_Jansheski)
#### 发布日期： [2018 年6 月 22 日 12:52 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/18 "2018-06-22T12:52:41Z")
Absolutely – that’s much nicer. I’ll take a look.
---
### 作者：  [@riking](https://meta.discourse.org/u/riking)
#### 发布日期： [2018 年6 月 23 日 00:33 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/19 "2018-06-23T00:33:35Z")
Another advantage to this over the whole line being a button is that text selection isn’t going to be an utter pain.
---
### 作者：  [@sam](https://meta.discourse.org/u/sam)
#### 发布日期： [2018 年7 月 2 日 05:27 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/20 "2018-07-02T05:27:16Z")
Note, Jay has unfortunately ran-out-of-time here, @j.jaffeux will be taking on this feature for 2.1.
---
### 作者：  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### 发布日期： [2018 年7 月 27 日 03:07 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/21 "2018-07-27T03:07:11Z")
I’m almost done on this:
On the screen you can see the two base “list” types available (in core and plugins): list and compact\_list
Will add more test and should probably be able to PR this tomorrow.
---
### 作者：  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### 发布日期： [2018 年7 月 27 日 03:20 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/22 "2018-07-27T03:20:57Z")
@sam should I keep the drag/drop behavior? If no, should I have a way to reorder it?
---
### 作者：  [@sam](https://meta.discourse.org/u/sam)
#### 发布日期： [2018 年7 月 27 日 03:25 UTC](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042/23 "2018-07-27T03:25:52Z")
I would not worry about order here for now. In general when you have long lists like this order does not matter. We can deal with this later.
[下一页](https://meta.discourse.org/t/better-handling-of-site-settings-with-large-amount-of-content-big-lists/90042.md?page=2)