DGSWishlist/ Not Implemented

Sub-page of DGSWishlist

The following items originally posted at the DGSWishlist will not be implemented by the established DGS-developers. Reasons to why that is are given below the corresponding items. Please use the [ext] Dragon Discussions forum, if you like to discuss as to why the feature is not going to be implemented.
Freshest entries are kept at top, oldest commented and moved on bottom.

% The context for the entries should be made clear (eventually add context) when copying item from the DGSWishlist.
% keep freshest entries/updates at top
  • Design Issues Game: option to deselect move confirmation: clicking a move automatically submits the move (and goes to next game?)
    • JUG(developer, 05-Jul-2009) This is per choice not done, because the danger to accidentally submit a (unwanted) move is high, even if this is wanted. This may be acceptable if there is an undo-feature, but there is no undo and there will be no undo be implemented (it's expected to be considerate enough before making and submitting a move; also see below item). Second, then there would also be no way (for non-JavaScript users) to add a game-message with the submitted move (also if no message is intended).
  • Statistics - User Stats:
    • number of running games per day, computed from user's start/end dates of all finished (/current?) games (how much simultaneous games did this player handle in the past?)
    • frequency of simultaneous games
    • JUG(developer, 02-Jul-2009) Currently running games of a user can be seen in the user-info ("Running games").
      Dragon is reluctant providing statistical calculations if there's limited use but the requirement of heavy load of the server. Even more so, if similar information can be determined with functionality already existing, though not in the same manner (or "quality").
      In the case of finished games of a user, the search function applied on a users finished games list provides the games (and therefore the number of finished games), which can be restricted to a certain time-frame filtering on the end-date for example. This should be more flexible than what is requested as it allows more "configuration" when doing such searches.
  • Statistics - User Stats:
    • average number of moves per day (for each finished (?) game, compute average number of moves per day; for each day, sum up the average number of moves of the games that were active that day.) (how often did this player play?)
    • JUG(developer, 02-Jul-2009) This can not be calculated from existing data (no absolute time is stored with each move, but only relative time). A "per day" stats requires an absolute time-frame, which is not available.
      This information would be useful to check if a potential opponent plays with the same pace as oneself. However, in a negative sense, this could also be used to avoid such users, either being too slow or too fast or the "move"-profile not matching ones own "move"-profile. Dragon doesn't want to "discrimate" users, if this information is not given freely (in waiting-room offer or in bio).
  • Statistics - User Stats: Notes on user stats
    • It would be handy to be able to compare with one's own stats, e.g. by superposing two graphs
    • JUG(developer, 02-Jul-2009) IMHO this is of limited use and can be "simulated" by opening the two pages with own and other users "graphs" using the same time-window and compare it "manually" by visually comparing them
  • Statistics - Go Stats: based on results of all games, what is the ideal komi (or distribution of komi) for a give board size and pair of grades (or: grade difference). For 19x19, the classic komi (currently 6.5) is expected. (and then: how about comparing this value against other servers)
    • JUG(developer, 02-Jul-2009) Likewise this is (1) too vague and (2) would need too much calculations. This request seems better suited as off-site analysis. Data can be provided for that purpose if someone wants to make a deeper analysis.
  • Statistics - Server Stats: [ext] user clusters
    • JUG(developer, 02-Jul-2009) To be of value, this would need quite some calculations, which would produce too much server-load. Instead off-site [ext] manual analysis published on DGS-forum is ok and data can be provided for that purpose if someone wants to make a deeper analysis.
  • Statistics - User Stats: Notes on user stats
    • these stats can be computed from existing data
    • JUG(developer) just removed this note from wishlist: it's natural, that stats can be computed from existing data
  • User profile: weekend clock setting: rather undecided, see discussions [ext] http://www.dragongoserver.net/forum/read.php?forum=4&thread=7013
    • transfer the weekend clock property from game to player objects. players can choose to change their weekend clock setting anytime, game clocks will continue during weekends only when both player's weekend clock settings are ON.
    • JUG(developer, 09-Jun-2009) Weekend remains as game-setting. Once set, the weekend-clock should not change during the game (which would make the time more unpredictable in tournaments for example). Besides, the referenced discussion was rather undecided indeed.
  • Menu: BenAxelrod: Provide a "heads up" display that uses the wasted screen region on the right. See my example at: [ext] http://www.gyoju.com/ben/headsup.jpg.
    • JUG(developer, 09-Jun-2009) Link not working, though whatever it is it may clutter the page too much (however, without seeing the picture it's only guessing).
  • Message - Notifications: [ext] notifications through ICQ
    • JUG(developer, 18-May-2009) See [ext] http://en.wikipedia.org/wiki/Icq#Criticism for reference (all of the criticism on Wikipedia are good reasons, that this is not going to be implemented): ICQ is no open protocol, quite the contrary to DGS which follows an "open" approach. Also ICQ is quite annoying in regard to privacy matters and copyright. On top of that AOL changes the underlying protocol often to counter reverse-engineering done by "inofficial" 3rd-party clients.
  • User-profile: Liso: possibility to set preferred number of games for change open for new games status automatically
    • JUG(developer, 17-May-2009) Not clear, what is wanted. This is propably asking for a user profile setting: but on what page to reach what goal?
  • Status-page: add the number of games in HTML page title (can be used in tabbed browsers to check if a game is available)
    • misomosi?: in [ext] page-title of status-page show number of running games to move in; for a visible check using browser-based auto-refresh
    • 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.+
      • OneWeirdDude: When a player has running games, but none are his/her turn, refresh every minute or five or something.
    • JUG(developer, 01-Feb-2009) There is a quick-status functionality and RSS-feed possible already, that can be used to alert a player of games to move in:
      • also see [ext] Add-Ons for DGS
      • How many games there are should be easy to comprehend by having a look on the status-page.
      • Simple using bandwidth because it's there (for auto-refreshing) is against providers policy.
      • Showing the number of games in the page title as indicator when there are games to play will too easily lead to use auto-refreshing functionality, which is a discouraged behaviour when too excessively used. It would be a waste and imbalance (for other users) of server-resources to load the complete status-page just to be able to see a single number.
      • Another, but minor dropback: also bookmarking the page would then contain a changing number.
  • General UI and Design issues: undo (propose as well as request)
    • JUG: better train to think "before" submitting ;-P also see discussion at [ext] http://www.dragongoserver.net/forum/read.php?forum=4&thread=4526
    • JUG(developer, 11-Jan-2009) Besides the discussion in the given link above, and after having asked Erik (site-owner) several times during the last three years about an "undo" (he too rejects it), there is another negative point around it caused by the turn-based nature of the server:
      When after submitting a move, the opponent starts to think about it and then the player takes a move back (with "undo") in the meantime, the opponent gets notice about that only after he tries to click/submit a move. Not a good policy, which can lead to an annoyed/angry opponent forced to "waste" his/her time.
  • user-info: show the basis of the initial rating (no reason to hide this, plus it justifies one's initial rating - see also [ext] http://www.dragongoserver.net/forum/read.php?forum=3&thread=3298
    • JUG(developer, 04-Jan-2009) The base for the initial rating is not and will not be saved into the database. It's just to have a start value. Other ranks can be added in the Rank Info field.
  • Messages: as messages are never physically deleted, clear the content of messages once both parties have destroyed them.
    • JUG(developer, 04-Jan-2009) I see no use in that. When difficult to remove unreferenced messages, better to keep them in total.
  • forum-list: new forums [ext] Problems, requirements
    • JUG(developer, 04-Jan-2009) average users seem to be "confused" by finer detailed forums. There have been some new forums and clarified description during the last year. That should be enough at first.
  • forum-search: filter for new messages only
    • JUG(developer, 28-Sep-2008, 21-Feb-2009) It's a rather limited use to search only in new messages, though it was probably requested to have a way to see "new" (=unread) messages. Besides that it would need a (very) complex query for such a search with additional recalculations on the thread-reads.
      Searching for the most recent forum posts is possible though (but without a marker if that is new or an already read post), see [ext] search for most recent forum posts
  • Forum Thread-List: reduce width of 'Topic' column (50% wasted space, due to author name and date fields sometimes using two lines)
    • JUG(developer) not changed, the current "width" is determined by the non-breaking columns. The column width is therefore browser-dependent (local resolution). Might even be more severe, because a column has been added.
  • User info: about adding user's timezone, night time:
    • pages containing the country flag should also have the timezone, to allow [ext] sorting on time zone
    • as the playing period info is available, on pages where the last user access time is printed
    • JUG(developer, 11-Aug-2008) showing the time-zone and night-time on other pages than user-info is of limited use (not added therefore), because the majority of users use the defaults (even if counted for the 'active' players only)
  • User info: about adding user's activity:
    • [ext] NPC: Activity histogram, that shows at which daytime the user usually makes moves. [ext] see here (item added by [ext] jbrod)
    • [ext] NPC: Data field that shows average moves per day and game of a user. [ext] see here (item added by [ext] jbrod)
    • JUG(developer, 12-Aug-2007, 10-Aug-2008, 09-Feb-2009) activity histogram will not be published as that would produce too much server-load.
      Providing additional information about user activity is against the policy set by the DGS founder: High activity is not considered a good thing. Much activity should not encourage to be very active too (DGS is a server to play SLOW games).
  • 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, 07-Oct-2007) 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, 07-Oct-2007) there is no longer a "flat view" (only a threaded view). Message date is shown on every post.
  • Running Games: [ext] Beckenbauer: How about enabling sorting of current games by country? (item added by [ext] jbrod)
    • JUG(developer, 07-Oct-2007) 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.
  • it should be possible to [ext] 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, 17-Aug-2007) 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.
  • Status page feature requests:
    • [ext] jbrod, Hikaru79: observed games with new moves show up on status page
    • [ext] jbrod: show observed games also in status list
      • JUG(developer, 12-Aug-2007) better keep the status page as small as possible, containing data about "your" status + see below's reasoning
    • JUG(developer, 12-Aug-2007) 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
  • Messages page: possibility to delete messages directly (i.e. without first moving then to the dustbin)
    • Rodival(developer, 12-Aug-2007) 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, 12-Aug-2007) In fact, Erik even wanted 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.
  • 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, 05-Aug-2007, 12-Aug-2007) this will not be done (taking too much bandwidth). See also [ext] Erik's opinion on that feature #1 [ext] #2 [ext] #3. 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 [ext] 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, 05-Aug-2007) 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

This is a copy of the living page "DGSWishlist/ Not Implemented" at Sensei's Library.
(OC) 2009 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About