notice

this is a remake of a suggestion i made in 2022. it's my personal favorite previous suggestion of mine, so i've decided to try it again. a few changes have been made (e.g. a verification system was been added to message d to keep it secure, the “gdpr message” concept previously used in the original suggestion was removed, etc.)

the original topic was closed by me, not the scratch team. if the original topic was closed by the scratch team, i wouldn't be trying this again.

that said, if this suggestion is closed and the given reason is specifically because message a qualifies as an online status indicator so it's considered rejected, i may reopen it with that part removed. if it's closed after that, however, i'll consider the entire thing rejected and give up on it.

another note: at the time i am writing this, cubeupload is currently down. refer to the image descriptions provided if the images do not appear for you.

hello! thanks for clicking on this topic! i am suggesting that various messages be added to scratch that can appear on people's “what i've been doing” section. one of four messages can appear, either automatically by the website or voluntarily by the user.

the messages that can appear are as follows:

message a.) the user hasn't formally marked their account as inactive, but they have not had a substantial amount of activity (meaning more than 10 comments, more than 10 forum posts, more than 5 new projects/remixes, more than 10 love/favorites on projects, or more than 10 instances of editing their account bio) in over 1 year. this is an automated process. if one of these instances of substantial activity is met, the inactivity message is automatically removed. in case a user logs into scratch after their account has been marked as inactive, an alert is sent to their account saying that their account was marked as inactive by scratch, and suggesting that they may want to formally mark their account status themselves through account settings. an account can manually turn on a checkbox in the account settings specifically telling scratch not to automatically mark this account as inactive, preventing this message from ever showing.

figure a-1: the message indicates that due to the lack of activity for over a year, the account is likely inactive.

figure a-2: an alert is shown on the user's account saying, “welcome back! scratch detected that your account did not have a substantial amount of activity in over 1 year, and automatically marked your account as inactive. if you would like to manually configure your account status yourself, please do so through the account settings page.” this alert is shown upon a user logging into scratch after their account is automatically marked as inactive.

message b.) the user has voluntarily marked their account as inactive, with no set return date, through the account settings page. they can manually turn this off through account settings, and scratch does not automatically turn this on or off. if this is turned on, it also overrides message a from happening.

figure b-1: the message indicates that they have marked their account as inactive, and they likely won't respond to any messages.

message c.) the user has voluntarily put their account in vacation mode. vacation mode will allow a user to go inactive either for a short-term or long-term period, with an estimated return date provided by the user. the return date can be set to be three days away (in case of short breaks, weekend vacations, etc.) to 1 year away (in case of school, moving, etc.) from the time that the date is set. despite the name, vacation mode does not have to be just used for vacations - it can be used for any reason. vacation mode is not a commitment, and the user can turn it off through account settings while it is active in case they end up returning earlier than expected. when vacation mode ends or a user turns it off early, figure c-1 will no longer appear on the “what i've been doing” section of a user profile.

figure c-1: the message states that the account has been placed in vacation mode, indicating that they likely won't be active until their estimated return date (in this case, january 1st, 2000.)

message d.) the owner of the account has voluntarily marked their account as moving to a new account through their profile settings, with a link to the new (or target) account provided. to prevent people from setting this message to say “i'm moving to @scratchcat!” or something like that, a complex four-step verification process will need to be completed in order to mark the account as moved, to prevent both trolls and hackers from starting false move requests.

1.) the source user enters the target user’s email and password through the “status” tab in account settings.
2.) the target user receives an alert message saying to expect an email for a move request, but not to accept it if they aren’t the same person as the target user or if the move request is being used as a means of sharing accounts. to prevent fake move request emails from spreading with malicious links, a 6-digit code will be displayed in the alert that the target user will need to write down.
3.) the target user’s assigned email address gets an email with a link to verify the move request, and an attached six-digit code.
3.5.) after verifying that the alert from step 2 and the email’s six-digit codes are the same, the target user clicks the link in the email.
4.) the target user enters the source user’s email and password to complete the move request.

this may look ridiculous and overcomplicated, but it is much, much more secure than just a system where the source user sends a request and the target user approves it. when these three verification steps are complete, the old account displays the message shown in figure d-1 until they remove it or edit it via account settings. if this newly verified target account moves to a brand new third account, they can set the new account name again, and upon completion of the new account verification, the first account will update the information with the third account's name accordingly and will continue to update with any newly created/verified accounts. if the target account accidentally accepts a request or they are using the old account again, they can remove or edit the new account name through account settings; if edited, a new request is sent to the edited account name. the account that sent the request can revoke it, or edit/remove it. again, if edited, the three-step verification must start again, with a new request being sent to the source user’s new targeted account.

accounts that have been marked as moved do not have statistics or account information transferred over to the new account and are in fact separate accounts entirely, meaning this suggestion does not violate rejected suggestion 8.1.

two accounts also cannot set each other as their target account, in order to prevent trolls who think that's funny.

figure d-1: a message is shown stating that the user has moved to a new account, with a link to the new account provided.

why i believe this is a good idea
i consider this suggestion to be a great way to stop rumors from spreading involving the whereabouts of dead accounts. for example, if a user's account is voluntarily set to message b, then there's a solid reason given, being “they just packed up and left”. that way, nobody starts suggesting “maybe they have a new account”.

all of these new messages besides will be configurable in a new tab on the account settings page.

the status page will have the following options:

• a checkbox for whether you want to enable vacation mode, with a estimated return date form showing if you turn it on.
• a box to automatically turn on message b.
• a box to prevent message a from ever showing on the account.
• a form to fill out a user's name to send them a message d request, as well as a button next to it to send said request.
• a button to save your changes.

figure e-1: the status tab of the account settings page, with a few options: an option to disable message a from automatically appearing, an option to turn on vacation mode and to set a date when the mode will end, a checkbox to mark the account as inactive, a checkbox to mark the account as moved, with a form below it asking for the target user's username, a button to the right of it used to send a move request, and a button at the bottom to save one's changes.

figure e-2: the account settings panel including a new “status” button where these new features can be set.

if a user is ever banned, they will still have the option to set their what i've been doing tab to message b automatically, and they will also still have the option to turn off message a from ever appearing. they can turn these on or off as much as they like whether they are banned or not. message c can also be turned off from the ban page if a user is banned, but they cannot be turned back on once they have been turned off.

if a message is set manually by the user, no other messages can be set, automatic or not, until the currently enabled one is turned off.

thanks for taking the time to read this suggestion. i really hope you liked it! if you have any concerns or feedback, or if this entire thing is actually rejected and i wasn't aware of it because i haven't been online in forever, please don't hesitate to let me know.

all mockups were made by @marc92020 or @minikiwigeek2; mockups edited by @minikiwigeek2.

support, some not everyone makes projects that they are leaving/on holiday/ and it's also hard to tell with forumers who only do forums often.

I actually thought of something like this, but this one is way better than what was my idea. Support, it’s easier to know if one is inactive and if someone goes on vacation or quits scratch they can make sure everyone knows.

One thing, perhaps for moved accounts you need to enter the password of the account you wanna say you moved to. Yk, to prevent trolls and people who’d do stuff like “this user moved to @*insertusertoimpersonate*” and stuff like that.

sorry for the big post
remaking some of my older mockups
automatic inactivity

inactive by user

vacation mode

status page in account settings

theres supposed to be a ban page mockup but there isnt yet. ill make one eventually (maybe in a few days or even tomorrow)

support, this would be very useful!

:D :: hat :: motion

Good suggestion. My only complaint is that I'm not sure what there is to be gained from phrases like “This user probably won't respond to any messages.” Why not just say that they are not active? I think the reason why I am bothered by this is that it sort of “assumes” the behavior of a particular account. If the purpose of the suggestion is to explain why a user is inactive, all that needs to be done is to state that.

If I were able to change the messages for each of your 4 situations, I would probably say the following:

(1) This user may be inactive, as they have not had any activity in over 1 year.

(2) This user has marked their account as inactive.

(3) This user has turned on vacation mode. They may not be active until January 1, 2000.

(4) This user has moved to a new account: @ExampleUser.

In the above, I also changed things like “this account” to “this user” to personify the user a bit more.

Finally, I'm not a fan of the “Hmm…” sentences. I think this was done to mimic another Scratch page (I forget which one), but it doesn't really seem all that useful, and the use of the word “Hmm” … just doesn't sound right, for some reason. I would just remove those sentences entirely — since each subsequent text already explains that the user is inactive, it doesn't need to be said again.

I want to be very very clear that I am only being picky about this suggestion because I really like it and I want to help make it better.

#6
thanks so much! i was actually curious what you thought of it lol. don't worry, your thoughts definitely helped this suggestion. i'll make sure your feedback is added!

Za-Chary wrote:

(1) This user may be inactive, as they have not had any activity in over 1 year.

-snip-

(3) This user has turned on vacation mode. They may not be active until January 1, 2000.

-snip-

i agree that these messages should be shortened and changed, however i have just two additional words i'd like to add to make it more clear.

1.) this user may be inactive, as they have not had any substantial activity in over 6 months.

there are some conditions that have to be set for message a to be triggered, as shown here:

minikiwigeek2 wrote:

the user hasn't formally marked their account as inactive, but they have not had a substantial amount of activity (meaning more than 10 comments, more than 10 forum posts, more than 5 new projects/remixes, more than 10 love/favorites on projects, or more than 10 instances of editing their account bio) in over 6 months

3.) this user has turned on vacation mode. they may not be active until roughly january 1, 2000.

as vacation mode is an estimate, i don't want it to sound like it's 100% guaranteed that the user will return on that particular date.

#4
thank you for the mockups! i have applied them to the op.

made an improved mockup for the account move status

minikiwigeek2 wrote:

3.) this user has turned on vacation mode. they may not be active until roughly january 1, 2000.

as vacation mode is an estimate, i don't want it to sound like it's 100% guaranteed that the user will return on that particular date.

I'd change “roughly” to “around” maybe.

Sorry if I missed it in the op, but will the message disappear when the return date is met? Or will it just stay there forever, a haunting memory of the last time that person signed on?

wouldn't this would be similar to is user online and also be rejected

-mage wrote:

wouldn't this would be similar to is user online and also be rejected

user online is a 1-0 output updated recently
this takes a year and has multiple inputs

OwO :: #44bd8d
^-^ :: #44bd8d

#11
the message will dissapear when the return date is met, yes. will fix the op so it makes more sense

#9
thanks! i was too lazy to turn off my browser extensions' themes lol

i’ve updated the mockups to follow za-chary’s suggestion! i personally think it looks much better and more clear!

starlightsparker wrote:

One thing, perhaps for moved accounts you need to enter the password of the account you wanna say you moved to. Yk, to prevent trolls and people who’d do stuff like “this user moved to @*insertusertoimpersonate*” and stuff like that.

i like this idea, but there’s a potential problem with it. if a really famous account’s password is compromised, there’s nothing stopping users from just claiming they own a user. so to fix that, i’ll actually make it a three-step process so it’s extra super duper secure.

1.) the source user has to enter the target user’s password.
2.) the target user has to accept the move request in their inbox.
3.) the target user has to input their password one more time to finalize their changes.

minikiwigeek2 wrote:

starlightsparker wrote:

One thing, perhaps for moved accounts you need to enter the password of the account you wanna say you moved to. Yk, to prevent trolls and people who’d do stuff like “this user moved to @*insertusertoimpersonate*” and stuff like that.

i like this idea, but there’s a potential problem with it. if a really famous account’s password is compromised, there’s nothing stopping users from just claiming they own a user. so to fix that, i’ll actually make it a three-step process so it’s extra super duper secure.

1.) the source user has to enter the target user’s password.
2.) the target user has to accept the move request in their inbox.
3.) the target user has to input their password one more time to finalize their changes.

That’s a great idea. Easy for the actual user, hard for hackers!

cactus-cacti wrote:

That’s a great idea. Easy for the actual user, hard for hackers!

that’s what i thought, until i realized it doesn’t actually since anything. if the target user’s password is compromised, there’s still nothing stopping the source user (aka the hacker) from sending a move request, logging into the target user’s account, and approving the move request and entering the password.

so instead, i’ve devised a better system that’s more complicated, but it is much, much more secure.

1.) source user enters the target user’s email and password.
2.) target user receives an alert message saying to expect an email for a move request, but not to accept it if they aren’t the same person as the target user or if the move request is being used as a means of sharing accounts. to prevent fake move request emails from spreading with malicious links, a 6-digit code will be displayed in the alert that the target user will need to write down.
3.) target user’s assigned email address gets an email with a link to verify the move request, and an attached six-digit code.
4.) after verifying that the alert from step 2 and the email’s six-digit codes are the same, the target user clicks the link in the email.
5.) the target user enters the source user’s email and password to complete the move request.

this way, the possibility of a move request being maliciously made is incredibly low. so many hurdles have to be jumped past in order for a hacker to get the move request to be submitted. they’d need the target user’s email and password, and the password for the target user’s email, and their own password and email for the source account. that’s five things they’d need some way to obtain, and unless the target user’s password is exactly the same for all of their website logins (which you absolutely should not do), acquiring all of that information is going to be really hard.

bump

this is a really good topic

it helps other people understand that a user isn't gonna reply to their comment anytime soon