But won't that problem still persist when you include the option to upload pictures to the site directly?

No, because the images can be resized during the upload process. Since they currently are stored off-site, this is not currently possible hence us having this discussion to begin with EDIT: @Captain Jordan - to my knowledge, it definitely isn't an if. It is merely far too unimportant to worry about at the time being. Significant features, bug-fixes, etc are far more important, thus image uploading won't really be thought about until it needs to be.

Though, cycling back to the beginning of the conversation, we have the ability to resize it in the embedding process.

If you mean doing it client-side on page load, consider the fact that this would have to be done for every profile picture on the page, and done every single load. It would have a devastating effect on load times. Obviously not something that is desirable.

@Mahz, I've noticed a problem with links in PM's wherein they don't leave the site when clicked, you're just taken back up to the top of the conversation.

But won't that problem still persist when you include the option to upload pictures to the site directly?

No, because the images can be resized during the upload process. Since they currently are stored off-site, this is not currently possible hence us having this discussion to begin with EDIT: @Captain Jordan - to my knowledge, it definitely isn't an if. It is merely far too unimportant to worry about at the time being. Significant features, bug-fixes, etc are far more important, thus image uploading won't really be thought about until it needs to be.

Though, cycling back to the beginning of the conversation, we have the ability to resize it in the embedding process.

If you mean doing it client-side on page load, consider the fact that this would have to be done for every profile picture on the page, and done every single load. It would have a devastating effect on load times. Obviously not something that is desirable.

No, that isn't what I'm suggesting.

A lot of people like recruiting from both casual and advanced. And a lot of people who fit in advanced don't yet dare go there because of the unfortunate elitism history that section had. Fortunately, not many of the elitists remain. Unfortunately, not nearly enough players remain in advanced. This new IntCk system should help on that. Quick thought... Will the system be able to "remember" the search parameters? Say if someone can't stand RPing in anime settings... Will it be able to remember that and consistently filter those away, or will said filter have to be enabled each time?

1. I think it'd be nice for users to be able to save a set of filters that they are commonly searching for. 2. And the system should remember the state of your current filter across sessions until you clear it (i.e. your current filter is saved to the database). It's this kind of thing that's not hard to implement but makes a system much more pleasant to use.

Oversized avatars can be draining on mobile users and people with slow connections. Just resize your avatar with 2 clicks and be done with it.

But won't that problem still persist when you include the option to upload pictures to the site directly?

No. Right now, you can go to massivewallpaperimages.com and paste the URL of an 8192×4608 image into the Guild's avatar box. Since the guild's code right now is 100% naive and trusting of the client (always a bad idea), every user will have to download that 8192x4608 image. If massivewallpaperimages.com has no-cache headers on their images, then everyone on the guild will have to download your avatar image every time they see it. That's why I depend on people to just follow the rules right now. Now, when I implement a system where users can upload their avatars to the guild and I can process their image, then the guild will resize and downgrade that 8192x4608 image into a 150x85 image. In other words, I will be able to enforce the 150x150 max-size constraint since I control the images. I currently do not control the images.

While I feel it could use some tweaking, I like the color layout. However, can we do something about this ugly font in the text editor?

I don't know what happened. Though I kinda got used to it since there's some space between the letters and it's easy to debug BBCode issues with this monospaced font. Maybe the guild just needs a different font for posts in general since it's hard for me to read Helvetica Neue (the default that my styling framework uses). For instance I don't like how capital-"I" and lowercase-"l" look identical.

Hm. I would suggest Times New Roman.

Maybe Verdana? The 'I' (i) is distinct from the 'l' (L), which seems to be your main gripe.

Could I suggest an "upvote" option?

A lot of people like recruiting from both casual and advanced. And a lot of people who fit in advanced don't yet dare go there because of the unfortunate elitism history that section had. Fortunately, not many of the elitists remain. Unfortunately, not nearly enough players remain in advanced. This new IntCk system should help on that. Quick thought... Will the system be able to "remember" the search parameters? Say if someone can't stand RPing in anime settings... Will it be able to remember that and consistently filter those away, or will said filter have to be enabled each time?

1. I think it'd be nice for users to be able to save a set of filters that they are commonly searching for. 2. And the system should remember the state of your current filter across sessions until you clear it (i.e. your current filter is saved to the database). It's this kind of thing that's not hard to implement but makes a system much more pleasant to use.

Oversized avatars can be draining on mobile users and people with slow connections. Just resize your avatar with 2 clicks and be done with it.

But won't that problem still persist when you include the option to upload pictures to the site directly?

No. Right now, you can go to massivewallpaperimages.com and paste the URL of an 8192×4608 image into the Guild's avatar box. Since the guild's code right now is 100% naive and trusting of the client (always a bad idea), every user will have to download that 8192x4608 image. If massivewallpaperimages.com has no-cache headers on their images, then everyone on the guild will have to download your avatar image every time they see it. That's why I depend on people to just follow the rules right now. Now, when I implement a system where users can upload their avatars to the guild and I can process their image, then the guild will resize and downgrade that 8192x4608 image into a 150x85 image. In other words, I will be able to enforce the 150x150 max-size constraint since I control the images. I currently do not control the images.

I'm aware of the fact that you do not. However, is it currently impossible for the server code to accept the image redirection, and then before displaying it, resizes it in the same way it would an uploaded image? It could cause an extra few calculations, but what prevents the server from essentially saying "This linked image is too large, so I'm going to scale it down before displaying it" and output the resized version?

Maybe Verdana? The 'I' (i) is distinct from the 'l' (L), which seems to be your main gripe.

I support Verdana. I'm not a big fan of serifed fonts on the web, and Verdana is a good compromise. Also check into the Google Webfonts, there's some good ones in there. This author goes over some top fonts. Source Sans in particular has a straight uppercase I(i), with a small tail on the lowercase l(L) for differentiating the letters.

No. Right now, you can go to massivewallpaperimages.com and paste the URL of an 8192×4608 image into the Guild's avatar box. Since the guild's code right now is 100% naive and trusting of the client (always a bad idea), every user will have to download that 8192x4608 image. If massivewallpaperimages.com has no-cache headers on their images, then everyone on the guild will have to download your avatar image every time they see it. That's why I depend on people to just follow the rules right now. Now, when I implement a system where users can upload their avatars to the guild and I can process their image, then the guild will resize and downgrade that 8192x4608 image into a 150x85 image. In other words, I will be able to enforce the 150x150 max-size constraint since I control the images. I currently do not control the images.

I'm aware of the fact that you do not. However, is it currently impossible for the server code to accept the image redirection, and then before displaying it, resizes it in the same way it would an uploaded image? It could cause an extra few calculations, but what prevents the server from essentially saying "This linked image is too large, so I'm going to scale it down before displaying it" and output the resized version?

That's an awful idea for folks on mobile and limited dataplans, especially considering Mahz's example.

No. Right now, you can go to massivewallpaperimages.com and paste the URL of an 8192×4608 image into the Guild's avatar box. Since the guild's code right now is 100% naive and trusting of the client (always a bad idea), every user will have to download that 8192x4608 image. If massivewallpaperimages.com has no-cache headers on their images, then everyone on the guild will have to download your avatar image every time they see it. That's why I depend on people to just follow the rules right now. Now, when I implement a system where users can upload their avatars to the guild and I can process their image, then the guild will resize and downgrade that 8192x4608 image into a 150x85 image. In other words, I will be able to enforce the 150x150 max-size constraint since I control the images. I currently do not control the images.

I'm aware of the fact that you do not. However, is it currently impossible for the server code to accept the image redirection, and then before displaying it, resizes it in the same way it would an uploaded image? It could cause an extra few calculations, but what prevents the server from essentially saying "This linked image is too large, so I'm going to scale it down before displaying it" and output the resized version?

That's an awful idea for folks on mobile and limited dataplans, especially considering Mahz's example.

According to my idea, all the data load would be on the server, since nothing more than our current 150X150 pictures would display. Perhaps I'm explaining my intent incorrectly.

No. Right now, you can go to massivewallpaperimages.com and paste the URL of an 8192×4608 image into the Guild's avatar box. Since the guild's code right now is 100% naive and trusting of the client (always a bad idea), every user will have to download that 8192x4608 image. If massivewallpaperimages.com has no-cache headers on their images, then everyone on the guild will have to download your avatar image every time they see it. That's why I depend on people to just follow the rules right now. Now, when I implement a system where users can upload their avatars to the guild and I can process their image, then the guild will resize and downgrade that 8192x4608 image into a 150x85 image. In other words, I will be able to enforce the 150x150 max-size constraint since I control the images. I currently do not control the images.

I'm aware of the fact that you do not. However, is it currently impossible for the server code to accept the image redirection, and then before displaying it, resizes it in the same way it would an uploaded image? It could cause an extra few calculations, but what prevents the server from essentially saying "This linked image is too large, so I'm going to scale it down before displaying it" and output the resized version?

That's an awful idea for folks on mobile and limited dataplans, especially considering Mahz's example.

According to my idea, all the data load would be on the server, since nothing more than our current 150X150 pictures would display. Perhaps I'm explaining my intent incorrectly.

What's the benefit between implementing this and implementing an image upload system? I'm not sure how fetching from a 3rd party site is going to be any cleaner/safer/less open to abuse than uploading.

A lot of people like recruiting from both casual and advanced. And a lot of people who fit in advanced don't yet dare go there because of the unfortunate elitism history that section had. Fortunately, not many of the elitists remain. Unfortunately, not nearly enough players remain in advanced. This new IntCk system should help on that. Quick thought... Will the system be able to "remember" the search parameters? Say if someone can't stand RPing in anime settings... Will it be able to remember that and consistently filter those away, or will said filter have to be enabled each time?

1. I think it'd be nice for users to be able to save a set of filters that they are commonly searching for. 2. And the system should remember the state of your current filter across sessions until you clear it (i.e. your current filter is saved to the database). It's this kind of thing that's not hard to implement but makes a system much more pleasant to use.

Thats exactly what we had in mind too... Good to know its not hard to implement.

No. Right now, you can go to massivewallpaperimages.com and paste the URL of an 8192×4608 image into the Guild's avatar box. Since the guild's code right now is 100% naive and trusting of the client (always a bad idea), every user will have to download that 8192x4608 image. If massivewallpaperimages.com has no-cache headers on their images, then everyone on the guild will have to download your avatar image every time they see it. That's why I depend on people to just follow the rules right now. Now, when I implement a system where users can upload their avatars to the guild and I can process their image, then the guild will resize and downgrade that 8192x4608 image into a 150x85 image. In other words, I will be able to enforce the 150x150 max-size constraint since I control the images. I currently do not control the images.

I'm aware of the fact that you do not. However, is it currently impossible for the server code to accept the image redirection, and then before displaying it, resizes it in the same way it would an uploaded image? It could cause an extra few calculations, but what prevents the server from essentially saying "This linked image is too large, so I'm going to scale it down before displaying it" and output the resized version?

That's an awful idea for folks on mobile and limited dataplans, especially considering Mahz's example.

According to my idea, all the data load would be on the server, since nothing more than our current 150X150 pictures would display. Perhaps I'm explaining my intent incorrectly.

What's the benefit between implementing this and implementing an image upload system? I'm not sure how fetching from a 3rd party site is going to be any cleaner/safer/less open to abuse than uploading.

It's a system that'll take less time to implement, won't require server space to implement, since images are stored elsewhere, and it makes it easier on users of the current system.

<snip>

It's a system that'll take less time to implement, won't require server space to implement, since images are stored elsewhere, and it makes it easier on users of the current system.

Mahz will eventually be implementing image uploading. Why would he spend the time to implement a system that allows users to use any avatar they want without them having to worry about the size, when he is going to eventually implement a system that will do the same thing anyways? The opportunity cost of implementing your system which will inevitably be deprecated is so low that it isn't worth it. If you care about it so much, perhaps implement it yourself? I have to disagree that the load will be on the server – but even if it is, it still will inhibit loading times, just to make trust in the user unnecessary. I'd like to think that the community is more than trustworthy enough to wait until image uploading is implemented, unless you think otherwise?

It's like watching two protégés squabble for the favor of their master.

It's like watching two protégés squabble for the favor of their master.

But I am the one and only master No, I'm just trying to get my point across. I don't see why such a system is worthwhile, and as I pointed out, if he feels it is important he can work on it himself, once his dev environment is set up.

Could I suggest an "upvote" option?

This is actually something I'm working on!

I'm aware of the fact that you do not. However, is it currently impossible for the server code to accept the image redirection, and then before displaying it, resizes it in the same way it would an uploaded image? It could cause an extra few calculations, but what prevents the server from essentially saying "This linked image is too large, so I'm going to scale it down before displaying it" and output the resized version?

Because it's an expensive operation and the resized image needs to be saved somewhere (instead of doing it every time). In other words, it involves implementing precisely the "hard" parts of a direct upload system. Whether the user is sending a request to my server with their image (i.e. file upload) or another server is sending a response with an image (i.e. my server making a request to someone's remote avatar URL), I have to do pretty much the same thing. Though in the time I've spent talking about this system I could've probably implemented it.

Thanks!! I'm new but you seem really dedicated to this community. @Mahz