Order of challenges...

Question - would it be possible to list the challenges so that when one was accepted or created, it didn't result in the entire list shifting up or down? It's fierce difficult to click on the seek one actually wants sometimes...

I agree. We are talking about live chess right?

they disappear and reappear in batches every 3 seconds. we can't leave them there forever :)

They could go in a rotating fashion.  Each new seek would occupy the next available slot, but then it wouldn't move.  As soon as the seek is accepted, is disapears, then another one will fill that slot. (edit:  That is a horrible explanation, just read the example)

example:

0 seconds

seek 1

seek 2

seek 3

5 seconds: seek 2 accepted.  New seek created (named seek 4)

seek 1

seek 4

seek 3

10 seconds: seek 1 accepted, no new seeks

(empty slot)

seek 4

seek 3

15 seconds, someone makes a new seek (seek 5)

seek 5

seek 4 

seek 3

and so forth.  It may look a little botchy towards the end of the list from time to time,  but seeks wouldn't move (and thus, they would be readable and acceptable)

Even though I have very little experience programming, I can't imagine it would be that difficult...

How about combining the seeks and games tabs so that once a game is started the accept link becomes an observe link?  At least that way you'd have more sort options that could be used to mitigate the jumping around, and half the number of tabs to maintain.

there would also be a manhunt for games to accept.

I second this.

Not if you sorted appropriately.

true...but you would pretty much have the same problem.  Once games are accepted, they change positions

As Erik has pointed out, you have to deal with the change in the status of seeks at some point -- my feeling is that combining the tabs would give the flexibility to either group all of the open seeks together, or to keep accepted seeks from jumping around -- at least until a game is completed.  I don't think there's any solution that lets you have it both ways.

Perhaps I can suggest another option:  I think it would help to only list those seeks that a user is able to accept -- this would mitigate a lot of the changes as many seeks are irrelevant to each user due to rating limit settings etc. and don't even need to be shown in the first place.

I don't actually think it should be that hard to do at all provided it's handled on the client side.

seek filters are coming in November :)

"seek filters are coming in November :)"

Thank GOD!

Well there you have it -- as usual, the chess.com staff is one step ahead of the masses.  I know I've said it before but it bears repeating:  You guys do great work.

I notice that the seek filters are in place and players can now filter their seeks by Game Time range, Rating Range (presumably the seek creator's rating?) and "Premium Only".  This is a great new feature that should help with this issue, but it seems to me that there the most relevant filter is missing: 

"Show only those games that I'm eligible to accept"

Isn't this the view that most players would be interested in seeing?  The seeks I can't accept are of no value to me, so showing them just adds unnecessary clutter.

excellent point!

I too have felt like complaining.  The thing is you just have to change the way you think about the seeks and list.  Create a fixed number of list entries to be used by seeks.  Then populate these blank dropdown entries with individual seeks, assigning each seek to a specific blank line on the list.  From the point of view of the collection record keeping track of the seeks, everything is pretty much the same as far as add() and del() goes.  In the iterator you need an additional variable to tell you which seek you are.  When a seek arrives, look through the list and find an empty line for your seek.  Set the seek iterator with the first empty list member.  This seek will stay on the same line until it is filled and deleted from the list.

I don't know the specifics of your language, but if the collection class does not behave exactly as you wish, wrap it in a class of your own definition that has the added functionality.  We managed to do stuff like this in the days of procedural languages, so you should be able to get OO languages like Java to work for you!

Clear as mud?

(NB Erik).

I personally have no particular problems with the seek list as it is now.

Using fixed lines, I don't understand how do you expect it to work when the list is sorted (for example, by rating). Or am I missing something?

The only enhancement I can think of at the moment would be separating my seeks (or resumes) so that they don't get sorted with the rest but always appear at the bottom (or top).

Keep up the good work.

Alessandro