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 (we might change our minds).
Freshest entries are kept at top, oldest commented and moved on bottom.

  • Login: Redirection from index.php to status.php if you are already logged in
    • Rodival(developer) Call directly the status.php page! We must let the users with more than one ID the ability to switch between them.
      • Status could still be the main page, with a link to the login page. This would be better for the majority of users.
    • JUG(developer, 20-Mar-2012) This will not be implemented. "Magic redirects" that are suddenly ending somewhere else will not be done. As Rod says, it's easy to directly go to the page you want.
  • Other Interfaces: Make separate GUI for WAP devices
    • JUG(developer, 20-Mar-2012) WAP is not so widely used anymore with fallen prices of internet-flats. There is the quick-do-suite providing an alternative interface to basic DGS functionality. There will be no additional special interface based on WAP implemented by the Dragon crew. Rather if someone wants to have WAP, he or she is free to establish a WAP-gateway using the quick-do-suite.
  • Other Interfaces: PStr: Standalone client - connect with server only for load/upload moves like email clients.
    • adammarquis: I wouldn't want the Dragon crew using up their time on this, but it sounds like a fun project for a programmer with some free time.
    • JUG(developer, 20-Mar-2012) Besides playing moves, reading the bulletins and private messages is also an important part of collaboration on DGS, so a stand alone client should implement at least that as well. Besides that, I agree with adammarquis. There's the quick-do-suite available that provides some of the basic DGS functionality via a JSON-based alternative interface. So if someone has the time to write a stand-alone client, he or she should be able to do so. Still it could mean a lot of work to implement a new GUI, so this probably has only meaning to someone who is deeply unssatisfied with the official DGS server GUI.
      However for the Dragon crew it makes no sense to build a 2nd GUI.
    • JUG(developer, 02-Oct-2016) In the meantime, someone implemented a separate (desktop) client: [ext] DGS desktop client - DGS Electric
  • Other Interfaces: SMTP Move Transaction Please!
    • JUG(developer, 20-Mar-2012) it's not planned to support a SMTP gateway for the live DGS-server. We don't want another "open" door, that may be exploited.
      However with the new quick-do-suite someone can easily setup a SMTP-gateway delegating mail commands (to-be-specified of course) to the quick-do-suite commands.
  • Public Team Accounts: Frs: use a user's current rating as the login password to switch to a DGS public team account
    • axd: Note: public team accounts died on DGS, and although asked to do so, nobody found it necessary to record what had happened with the idea, why it was useful (or not).
    • JUG(developer, 20-Mar-2012) public team accounts will not be done. I can't see this as useful and agree on axd's opinion.
  • User Stats: user's opponent relative (+1, +2, etc.) rating distributions (a "good" player should (equally?) play with players above and below his rank)
    • JUG(developer, 20-Mar-2012) too much number crunching and it's not really clear what is wanted.
  • User Stats: To refine: stats about time-outs, resign
    • JUG(developer, 20-Mar-2012) dedicated numbers about time-outs or resign-counts will not be added as certain numbers are very static for a set timeframe, so the use would be very limited.
      What is possible already is to search the game-lists of specific users and filter on game-results like timeouts or resignations. Advantage is, that the search can be very flexible spanning all kinds of additional criteria (the only disadvantage with this is that there's no direct count of found results except if browser-counts are enabled). So if you are lucky this is kind of implemented, even though not available right away without a search.
  • Running games: axd: [ext] indication of expected play load based on running games (how often do a player needs to check DGS)
    • JUG(developer) this may be against the users' activity privacy -> axd: see forum thread for reply
      • JUG(developer, 20-Mar-2012) detailing on players activity is not wanted by site-owner as it should not lead to players being avoided because playing less. The focus on DGS is to play SLOW games.
  • Finished games: axd: time information: use designated SGF properties to store time allotted (TM), time used by players (W/BL) (or time left at end of game) - if possible, show how much time the players consumed.
    • Rodival(developer) Two problems:
      1) All SGF timings are in seconds with no specification about the upper limit. Few months expressed in second give a big number that could disturb some SGF viewers. Do you have any info about that?
      2) How do you compute the time left with each byo-yomi type?
    • JUG(developer, 20-Mar-2012) there are no known plans to amend/extend/adjust the SGF-specs, and even so still some clients might have problems parsing/showing such big timedate-points. So for now this is not done.
    • see also [ext] http://www.dragongoserver.net/forum/read.php?forum=2&thread=43251
  • Status-page: sorting status-games to move in by other criteria:
    • opponent's last access (to play more often with opponents that currently are on line)
    • JUG(developer, 14-Mar-2012): General NOTE:
      • A sort on the games on the status page must also be bound to "showing next game" on the game page. So ordering needs special handling and is constrained to very few criteria. It's also NOT using the standard ordering used for tables.
      • An additional restriction is that it must be efficient (keep low server-load: some "sorts" are far from being efficient).
      • Sorting by opponents-last-access is such an inefficient query. However, the games can be manually picked as there's a new column available "User online" (within the last 10min), so using some cherry-picking though manually is possible.
  • Current game: button to turn coordinates on/off while viewing a game
    • JUG(developer, 14-Mar-2012): limited use IMO; open profile in another window, change coordinates-settings (perhaps only with browser-dependent settings), then reload the game-page has the same effect.
  • Ratings: Implement Glicko (?) (from DGS todo-list)
    • JUG(developer, 15-Feb-2012) Clicko have been partly implemented already. However, the current rating-systems works quite well and it's not clear/proved, that Glicko performs (much) better on turn-based servers.
  • 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 many 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 "discriminate" 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?
  • 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.
    • JUG(developer, 18-Nov-2016) A "delete"-button had been added to a single-message and a "delete marked"-button in the message-list to provide a shortcut to move a message into the trashcan. Additionally an "Empty trashcan"-button has been added on the trashcan-folder message-list, so it's easier to remove all trashed messages at once.
  • 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 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
  • 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.
    • JUG(developer, 30-May-2010) With release DGS 1.0.15 (at least) it will be possible to "hide" the Reply-Folders on the status-page.
  • 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. DGS is a Go-server, where the games SHOULD "drag on", so its intention are SLOW games.

DGSWishlist/ Not Implemented last edited by JUG on November 18, 2016 - 01:19
RecentChanges · StartingPoints · About
Edit page ·Search · Related · Page info · Latest diff
[Welcome to Sensei's Library!]
RecentChanges
StartingPoints
About
RandomPage
Search position
Page history
Latest page diff
Partner sites:
Go Teaching Ladder
Goproblems.com
Login / Prefs
Tools
Sensei's Library