DGSWishlist/ Not Implemented
The following items originally posted at the DGSWishlist will not be implemented. Reasons to why that is are given below the corresponding items. Please use the
Dragon Discussions forum, if you like to discuss as to why the feature is not going to be implemented.
- game-page: replace the "view move" button and the adjacent combobox with a "view previous move"/"view next move" button group (functioning as back/forward navigation buttons)
- JUG(developer) this will not be done (taking too much bandwidth). See also
Erik's opinion on that feature. Use SGF-download instead! What will be implemented is: selecting a move from the combobox will trigger the "view move"-button if JavaScript enabled (saving one click).
- status page auto-refresh: once the user is back on the status page, setup a reload in the next 30 seconds (say for the next 5 or ten minutes), then in 1 minute increments, 5 minutes increments, etc. (This and the previous proposal should be fairly easy to write and would greatly improve the game speed when both players are available at the same time. See also
this talk for another way to do it.)
- Phelan: I don't like this idea. That would cause a lot of load on the server, not to mention that some won't like pages refreshing automatically. There are other ways to do this, see the DragonGoServer page for one.
- I understand. It could be disabled by default, and the auto-refresh could stop after a certain number of refresh.
- JUG(developer) this is not done (too much load, even if configurable); we are urged (by DGS provider) to keep the server-load as low as possible
- axd: to improve browsing listings (finished games, users, messages?), listings allow to jump to a specific page (now, there is only "next page","previous page" links); listing header shows number of records to have an idea of quantity; records are numbered (column can be hidden).
- JUG(developer) this will not be done: It's putting too much load on the database-server to get this information. The first database query is the normal one showing only the extract part you see (e.g. 20 rows out of 1000). A second query, then would be needed to make a count of how many records would match that condition. So only to show the additional number of how many pages there are in total would double the server-load for a particular query. The cost-benefit ratio is too bad to justify that feature. See also
http://www.dragongoserver.net/forum/read.php?forum=4&thread=13147
- Status page feature requests:
-
jbrod, Hikaru79: observed games with new moves show up on status page
-
jbrod: show observed games also in status list
- JUG(developer) better keep the status page as small as possible, containing data about "your" status + see below's reasoning
- add the number of games in HTML page title (can be used in tabbed browsers to check if a game is available)
- Phelan: display the number of games in the title (which is shown in the tab title in many browsers), so that a user doesn't need to actually see the page to know some games are waiting for him/her. The title text should include the number first like "No go game pending"/"2 go games pending", etc.
- JUG(developer) this would also make a changing bookmark, which people don't want
- JUG(developer) these will all not be done. The status page is one of the mostly called pages. The additional information requested above already is available somewhere on the pages, even if not directly, and even if it needs some navigating to reach there or some memorizing (observed games).
The additional informations would need additional database queries, which would be a considerable increase of the server-load.
- for "new moves of observed games": Games -> Show observed games -> check for last-moved date
- for "number of games (to play in)": would be an additional count request, because the status-page shows not ALL your running games in which it's your turn if there are many.
- User info: about adding user's timezone, night time, activity:
- add user's timezone,
GMT offset
- pages containing the country flag should also have the timezone, to allow
sorting on time zone
- as the playing period info is available, on pages where the last user access time is printed
- show whether the user is within his playing hours (to get a rough idea of currently available players); e.g. show "3.5 hours before sleep" (so he is eligible for playing), or "7 hours before wake up" (so probably he is asleep);
- some flag/column/checkmark that shows if the user is (supposed to be) asleep/awake
NPC: Activity histogram, that shows at which daytime the user usually makes moves.
see here (item added by
jbrod)
NPC: Data field that shows average moves per day and game of a user.
see here (item added by
jbrod)
- JUG(developer) neither timezone nor night time nor activity histogram will be published, as that would allow cheating on time or produce too much server-load for the latter. Providing additional information about user activity is against the strict privacy policy set by the DGS founder. It would also be a disadvantage on players with some "exotic" timezones getting less potential players with interest to play with them;
there's always the possibility to use forums to find players in your "timezone".
- Messages page: possibility to delete messages directly (i.e. without first moving then to the dustbin)
- Rodival(developer) This will not be done, but marking multiple messages helps.
- axd: sorting should be more intuitive, and unlimited (currently only 2 sortings are possible; a button should be provided to clear the sorting): each click on a column applies a further subsort (and not a main sort as is the case now).
- JUG(developer) In fact, Erik even wants to restrict the sort to one field as the sorting was widely used as surrogate to find something (sorting + browsing). With the filters added that is no longer needed. There will be not more than 2 sorts (sorting has bad influence on server-load, because the database might need a manual sort instead of using indexes).
Besides of that, applying a further subsort (instead of a main-sort on a click) would raise the problem, that a sort reset will be needed too.
- it should be possible to
move game invitation messages to a separate folder, for example when one cannot / does not want to accept immediately an invitation, but put it "in the fridge" to declutter the Status page (now, invitations stay in the Reply! folder, which is always visible).
- JUG(developer) The messages are kept in the Replied folder, because they need to be replied ;-P The "Reply"-folder has this special meaning, that such messages are stored until they have been answered. If you don't want to accept an invitation immediately better reject it, then move the message into a "Later" folder for example, and then later send a new invitation. Every month ca. 200-300 invitations stay unanswered. If we could avoid this, the games table could be kept smaller and queries are more efficient.
- notifications are a bit difficult to read: for own games, instead of the Black/White format (needless clutter), remove my name from the message - I know it is a game of mine.
- JUG(developer) a person may have more than one account, so the name/userid makes sense to them
- Forums: headers of flat view of a topic should contain the <new> indicator (if applicable), and the date/time of the message
- JUG(developer) there is no longer a "flat view" (only a threaded view). Message date is shown on every post.
- Running Games:
Beckenbauer: How about enabling sorting of current games by country? (item added by
jbrod)
- JUG(developer) This would make another 2 columns (country for B/W) in the (already big) games table list. The players' countries are only one click away in the respective user info. IMHO, the server-load this produces doesn't justify to implement such a sort.
- Use AJAX to improve the speed of the game, reduce webserver usage and the enjoyment of users (because it doesn't need to reload all the game pages,as an ajax script could load all the pending game, let the user play his move and confirm that, and then send all the data to the server).
- JUG(developer) DGS' base policy is not to use JavaScript for main-functionality (if possible), AJAX (Asynchronous JavaScript and XML) would need to add JavaScript everywhere