improve update process (automatic checks+notification)

tooomm commented 6 years ago

The problem right now is that most users don't know or realize when new updates are available. We announce on several channels, but we never reach the majority of users. It would be easier for players if the client would let them know, that way their update process is smoother and makes it convenient to upgrade. It would also lead to a more homogenous client distribution and less outdated clients in general. Quicker fixed known issues, fewer bugs and earlier access to new features. 👍

One option to easily get them informed in time is to have a little update check run recurrently on app start for example. Or only the first start of each day, or once a weekly etc. To archive that, recycling the GitHub API call we have in place in the updater (implemented in https://github.com/Cockatrice/Cockatrice/pull/2515 by @Daenyth) might be an option. The result of the check is either no new version available --> do nothing, or show a little notification with the version + offer update possibility.

Notification look

Very simply notification showing only a hint + Version x.y.z (& link to release notes/changelog) Two buttons:
- Update: Open in-client updater --> like saying "hell yes, do it!"
- Ok: Close notification --> like saying "good to know, thanks. maybe later." Asking the user if he wants to update and have Yes/ No (or Ok/Cancel) is also possible, but has conflicts with another feature idea (see additional options, first bullet point) because hitting No or Cancel wouldn't imply that the selected check box is recognized and applied.

The user workflow for updating itself wouldn't change, they are running the same updater and installer. We just help them find the option and let them know in time!

I think something like this it has to be a very subtile notification (like no popup - just a clickable, but visible note somewhere in the interface) or the user needs some control for the more prominent notification. Because it seems easier to have the notification dialog for now, I have several additional options mostly regarding user experience to keep the annoyance level down and the information level still high:

Have a tick-box in the simple update-available-notification to allow users to suppress repeated notifications for the same version, if they don't like to install it. [ ] Don't show notifications for this version anymore
Have a pulldown menu in settings to adjust the frequency of the check (+disable completely) Automatically check for newly available updates on start-up: [ never / always / daily / weekly / monthly ] A good default could be daily or weekly.
Utilize a QStatusBar at the bottom of the client to show useful information like client version, ongoing check for new versions (in case it takes a while or there might be little lags in client for bad connections or older hardware - so the users are aware why) or other card database stuff like amount of sets enabled (# of cards shown) and creation date of database to show up-to-dateness etc.pp A lot of possibilities here. The Qt documentation mentions explanations for buttons on hover to help with guiding the user in the UI for example.

I'm sure there are other approaches to do the check, or maybe even better workflows for the user. Share your thoughts and ideas here, so we can find a good solution! 👍

woogerboy21 commented 6 years ago

Per @tooomm request here are the top client version (triple digit or more) counts seen on the woogerworks server:

+-------------------------------------+-------+
| client_ver                          | count |
+-------------------------------------+-------+
| 2.3.17 (2017-05-05)                 | 34875 |
| dab7316 (2017-01-19)                | 21248 |
| 277d7e2 (2016-06-30)                | 17312 |
| d55e44e (2015-09-23)                | 15573 |
| f7c8651d (2016-12-30)               |  6146 |
| 3498b16 (2016-10-30)                |  5771 |
| dc6c375 (2017-04-15)                |  4870 |
| 6e723b2 (2017-03-14)                |  4699 |
| ef7670a (2017-03-31)                |  3284 |
| 2e3966a (2016-04-16)                |  1787 |
| 323fc06 (2016-02-02)                |  1737 |
| 3c58003 (2016-03-22)                |  1726 |
| 2.4.0 (2017-11-19)                  |  1575 |
| cbea432 (2016-03-08)                |  1473 |
| cf3e172 (2016-05-17)                |  1440 |
| ff1091a (2016-04-27)                |  1224 |
| e3fb308 (2016-05-08)                |  1186 |
| f217551 (2016-03-30)                |  1171 |
| f7c8651 (2016-12-30)                |   681 |
| 948a5c6 (2016-04-05)                |   679 |
| e81a6d4 (2016-06-21)                |   673 |
| b4d5721 (2016-04-09)                |   639 |
| fffc3e7 (2016-05-12)                |   574 |
| 535e19f (2016-03-18)                |   570 |
| d75a0d8 (2016-06-04)                |   564 |
| 0b8f52e (2016-02-28)                |   532 |
| bfbbedd (2016-06-17)                |   486 |
| 17925ce (2016-03-05)                |   465 |
| 4ffec33 (2016-05-28)                |   430 |
| c213b67 (2016-04-25)                |   422 |
| 93d4f78 (2016-02-10)                |   415 |
| 768a1c5 (2016-04-12)                |   406 |
| cddb450 (2016-02-07)                |   356 |
| 2ab3209 (2016-05-06)                |   340 |
| c19f225 (2016-06-26)                |   326 |
| b40d9da (2016-06-13)                |   319 |
| 47de7be (2016-06-01)                |   305 |
| 49c22f3 (2016-02-25)                |   290 |
| 8d67c75 (2016-04-08)                |   287 |
| f7d1802 (2016-06-08)                |   258 |
| bf42319 (2016-02-20)                |   258 |
| f6a3551 (2016-06-15)                |   240 |
| 11dfee4 (2016-04-15)                |   235 |
| c095daa (2016-06-30)                |   233 |
| 2d43ab9 (2016-02-17)                |   222 |
| 2.3.18-beta004 (2017-06-28)         |   221 |
| 6a152ff (2016-07-05)                |   206 |
| 82742bb (2016-06-11)                |   205 |
| 66634c9 (2016-02-22)                |   194 |
| 36f1536 (2016-02-14)                |   194 |
| d16fab9 (2016-03-03)                |   173 |
| d75d694 (2016-04-14)                |   144 |
| 7d0d0f4 (2016-05-05)                |   134 |
| 3ba3f1e (2016-02-27)                |   131 |
| 5753764 (2016-05-16)                |   125 |
| 4e198bd (2016-06-03)                |   112 |
| webclient-0.2 (2016-08-03)          |   112 |
| 9807bcb (2016-06-29)                |   111 |
| e05e6ae (2016-07-03)                |   108 |
| d51a6c1 (2016-06-04)                |   108 |
| ef62261 (2016-04-05)                |   101 |

Daenyth commented 6 years ago

Is that over all time or just recently?

On Fri, Dec 1, 2017 at 3:37 PM woogerboy21 notifications@github.com wrote:

Per @tooomm https://github.com/tooomm request here are the top client version (triple digit or more) counts seen on the woogerworks server:

+-------------------------------------+-------+ | client_ver | count | +-------------------------------------+-------+ | 2.3.17 (2017-05-05) | 34875 | | dab7316 (2017-01-19) | 21248 | | 277d7e2 (2016-06-30) | 17312 | | d55e44e (2015-09-23) | 15573 | | f7c8651d (2016-12-30) | 6146 | | 3498b16 (2016-10-30) | 5771 | | dc6c375 (2017-04-15) | 4870 | | 6e723b2 (2017-03-14) | 4699 | | ef7670a (2017-03-31) | 3284 | | 2e3966a (2016-04-16) | 1787 | | 323fc06 (2016-02-02) | 1737 | | 3c58003 (2016-03-22) | 1726 | | 2.4.0 (2017-11-19) | 1575 | | cbea432 (2016-03-08) | 1473 | | cf3e172 (2016-05-17) | 1440 | | ff1091a (2016-04-27) | 1224 | | e3fb308 (2016-05-08) | 1186 | | f217551 (2016-03-30) | 1171 | | f7c8651 (2016-12-30) | 681 | | 948a5c6 (2016-04-05) | 679 | | e81a6d4 (2016-06-21) | 673 | | b4d5721 (2016-04-09) | 639 | | fffc3e7 (2016-05-12) | 574 | | 535e19f (2016-03-18) | 570 | | d75a0d8 (2016-06-04) | 564 | | 0b8f52e (2016-02-28) | 532 | | bfbbedd (2016-06-17) | 486 | | 17925ce (2016-03-05) | 465 | | 4ffec33 (2016-05-28) | 430 | | c213b67 (2016-04-25) | 422 | | 93d4f78 (2016-02-10) | 415 | | 768a1c5 (2016-04-12) | 406 | | cddb450 (2016-02-07) | 356 | | 2ab3209 (2016-05-06) | 340 | | c19f225 (2016-06-26) | 326 | | b40d9da (2016-06-13) | 319 | | 47de7be (2016-06-01) | 305 | | 49c22f3 (2016-02-25) | 290 | | 8d67c75 (2016-04-08) | 287 | | f7d1802 (2016-06-08) | 258 | | bf42319 (2016-02-20) | 258 | | f6a3551 (2016-06-15) | 240 | | 11dfee4 (2016-04-15) | 235 | | c095daa (2016-06-30) | 233 | | 2d43ab9 (2016-02-17) | 222 | | 2.3.18-beta004 (2017-06-28) | 221 | | 6a152ff (2016-07-05) | 206 | | 82742bb (2016-06-11) | 205 | | 66634c9 (2016-02-22) | 194 | | 36f1536 (2016-02-14) | 194 | | d16fab9 (2016-03-03) | 173 | | d75d694 (2016-04-14) | 144 | | 7d0d0f4 (2016-05-05) | 134 | | 3ba3f1e (2016-02-27) | 131 | | 5753764 (2016-05-16) | 125 | | 4e198bd (2016-06-03) | 112 | | webclient-0.2 (2016-08-03) | 112 | | 9807bcb (2016-06-29) | 111 | | e05e6ae (2016-07-03) | 108 | | d51a6c1 (2016-06-04) | 108 | | ef62261 (2016-04-05) | 101 |

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Cockatrice/Cockatrice/issues/2924#issuecomment-348608240, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA5NFfR_zHrEVG92mqbqQOG2YEM-_moks5s8GOTgaJpZM4QkSKE .

woogerboy21 commented 6 years ago

That data is recorded at the last login of the users account and everytime they log in the client_version they are using is updated for there account. Each user id in the database has a unique analytic table entry for the client version they last logged in with.

The oldest record is dated 2016-03-02 05:19:54 and the newest record is dated 2017-12-01 16:08:42 . If you like I can re-query with a smaller date range though honestly the top so many are going to probably be with-in the last 6 months to a year.

woogerboy21 commented 6 years ago

Here is just this years logins:

+-------------------------------------+-------+
| client_ver                          | count |
+-------------------------------------+-------+
| 2.3.17 (2017-05-05)                 | 34874 |
| dab7316 (2017-01-19)                | 21248 |
| f7c8651d (2016-12-30)               |  6145 |
| dc6c375 (2017-04-15)                |  4870 |
| 6e723b2 (2017-03-14)                |  4699 |
| ef7670a (2017-03-31)                |  3285 |
| 2.4.0 (2017-11-19)                  |  1579 |
| d55e44e (2015-09-23)                |  1538 |
| 277d7e2 (2016-06-30)                |  1210 |
| 3498b16 (2016-10-30)                |   691 |
| f7c8651 (2016-12-30)                |   681 |
| 2.3.18-beta004 (2017-06-28)         |   221 |

woogerboy21 commented 6 years ago

Last 3 months:

+-------------------------------------+-------+
| client_ver                          | count |
+-------------------------------------+-------+
| 2.3.17 (2017-05-05)                 | 21662 |
| dab7316 (2017-01-19)                |  8039 |
| f7c8651d (2016-12-30)               |  1793 |
| 2.4.0 (2017-11-19)                  |  1581 |
| 6e723b2 (2017-03-14)                |  1528 |
| dc6c375 (2017-04-15)                |  1368 |
| ef7670a (2017-03-31)                |   903 |
| f7c8651 (2016-12-30)                |   226 |
| 2.3.18-beta004 (2017-06-28)         |   165 |

woogerboy21 commented 6 years ago

Last 1 month:

+------------------------------------+-------+
| client_ver                         | count |
+------------------------------------+-------+
| 2.3.17 (2017-05-05)                | 10980 |
| dab7316 (2017-01-19)               |  5148 |
| 2.4.0 (2017-11-19)                 |  1581 |
| f7c8651d (2016-12-30)              |  1091 |
| 6e723b2 (2017-03-14)               |   862 |
| dc6c375 (2017-04-15)               |   727 |
| ef7670a (2017-03-31)               |   499 |
| f7c8651 (2016-12-30)               |   154 |

woogerboy21 commented 6 years ago

If other operators are curious as to the query I use to grab this data it is:

select client_ver,count(*) as count from servatrice.cockatrice_user_analytics where last_login >= (now() - interval 1 month) group by client_ver order by count desc;

Change the interval to the time frame you like or completely remove it to see everything

tooomm commented 6 years ago

Thank you for all the data @woogerboy21!

Off-topic: I'm wondering why there are two different entries of the same commit (one is cut down to 7, the other to 8). Why would that happen? Is it the client reporting it wrong?

| f7c8651d (2016-12-30) | 1091 | and f7c8651 (2016-12-30) | 154 |

If you put both commit hashes here without code wrappings they link to the same commit

f7c8651d (2016-12-30) --> f7c8651d (2016-12-30)
f7c8651 (2016-12-30) --> f7c8651 (2016-12-30)

We could cut all data in that table down to 7 digits. I think that's how Cockatrice deals with the commit hash anyway. No idea why this one is different. And there are many people using that version, weird.

woogerboy21 commented 6 years ago

@tooomm Yes, the client version string is sent from the client to the server via the users side client itself and is simply stored in the DB table with no manipulation done server side. So if those are the same client version than they would be reported differently between the clients at login.

Maybe some type of custom compiled client?

tooomm commented 6 years ago

@woogerboy21 I'm just assuming that they are the same, but they show the same date too. I guess it's the commit hash (see end of link) https://github.com/Cockatrice/Cockatrice/commit/f7c8651d51b6aed6b0ea752fff612b9369470800 cut down to f7c8651 (7 digits) and f7c8651d (8 digits) respectively.

I think the client cuts down to 7 digits, the same as GitHub does in their Webinterface within PR's for example. But somebody would need to check the code to be sure. Or maybe @ctrlaltca knows? We use it in the updater as well.

Maybe some type of custom compiled client?

Most likely, but over 1k users for that is odd. Even 100 is. :D It could be pre-compiled versions by @skwerlman though?

is simply stored in the DB table with no manipulation done server side

Would it be reasonable to cut them down to 7 digits for commit hashes (non tags)?

woogerboy21 commented 6 years ago

Unless there is a bug, wouldnt server side manipulation eliminate the point of storing the value(s)?

tooomm commented 6 years ago

Unless there is a bug, wouldnt server side manipulation eliminate the point of storing the value(s)?

Since it should only affect github commit hashes it would be more of a normalization instead a real manipulation. But yes, servers should not be involved there. The clients should report it correctly and in uniform manner in the first place. So normally there is no problem or confusion.

Daenyth commented 6 years ago

I don't think it's worth trying to normalize the commit IDs, we only use them for audit purposes and there are cases where they can be different. For example, commit abc can refer to a single non-ambiguous git object at a point in time, and then later as the repository grows, a second commit gets added which abc could also refer to - from that point git will print out abcd instead so it remains non-ambiguous. Stripping down isn't safe.

tooomm commented 6 years ago

there are cases where they can be different. For example, commit abc can refer to a single non-ambiguous git object at a point in time, and then later as the repository grows, a second commit gets added which abc could also refer to - from that point git will print out abcd instead so it remains non-ambiguous.

Ok, good to know! Maybe that was the cause here.

So back to the initial issue. 👍

Cockatrice / Cockatrice

improve update process (automatic checks+notification) #2924