New Feature: Profile Photos

Is the MacRumors Members Photo Directory, which is an index into the MacRumors pics! thread, still of use now that people can put photos in their profiles? I don't know whether to adjust the tags in the Photo Directory to make it work again under vBulletin 3 (a task in progress), to switch it to point at profile photos instead, to try to do both at once, or to abandon it as a no-longer-needed resource.

I would like to hear opinions from other members. If this resource is still useful to enough people, I'll adapt it as necessary and continue maintaining it. If not, that's fine too. My feelings will not be hurt either way.

Suppose a member posts N photos to the Pics thread. Previously, there were up to N+1 images available:

* Their avatar, as shown in posts and their member profile.
* The N photos they posted to the Pics thread.

The Photo Directory was presented this in the form

membername: photo, photo, ...

where membername was a link to the profile (where you could see the avatar) and the photos were links to the Pics thread photos.

Now we have up to 2N+2 images available:

* Their avatar, as shown in posts and their member profile.
* Their member photo, as shown in their member profile.
* The N thumbnails of the photos they posted to the Pics thread.
* The N photos they posted to the Pics thread.

(Some members don't have avatars, some won't have posted member photos, and there are no thumbnails where they posted a link to a photo at a separate URL instead of attaching it.)

We can use the same form as before:

membername: photo, photo, ...

but we can also consider changing the Directory in a number of ways, such as adding links to avatars, the actual avatars, links to member photos, the actual member photos, and/or thumbnails of the photos posted in the Pics thread.

Here are examples of some of these combinations. As my test case, I looked for the highest ranked member who has posted a member photo AND posted an attached photo in the Pics thread. It turned out to be everyone's friend übergeek. You can really click the links or thumbnail photos in these examples to see how they work.

1. Regular:

übergeek: photo, photo

2. With a link to the member photo:

übergeek: member photo, photo, photo

3. With avatar:

übergeek: photo, photo

4. With both:

übergeek: member photo, photo, photo

5. With member photo:

übergeek: photo, photo

6. With thumbnails:

übergeek:


7. With everything:

übergeek:


Note that the a text-only approach will make the Directory load quickly and make it easy to scroll thru the list of members. This suits looking for a particular member efficiently. On the other hand, adding images make it possible to browse through the member list as a gallery. This makes it harder to look up one member quickly and easier to see what "everyone" looks like.

My opinion is that Example 2 and Example 5 are the best candidates. But I'd like to hear what others think before I start formatting the data.

übergeek said:

aw thanks a lot Doctor Q for using me as an example

Click to expand...

You won in a fair fight, being the highest posting member with both a profile photo and a Pics attachment. You'll only owe me a "small" publicity fee. Nothing out of the ordinary by Hollywood standards.

The vBulletin change that I needed is now complete, so I am beginning the changes to switch to the new attachment numbers, which will make the Photo Directory functional again. I will use the format in "Example 2" above unless/until public opinion says otherwise.

For member profile photos, I think 100x100 was fine, and bigger than 150x150 is unnecessary. If people want to show off every pixel of their pearly whites, they can post in the MacRumors pics! thread or link to a photo from their signature.

Also, if we make a gallery (which sounds like a job for me, doesn't it?), we'd want to use a grid, so all rows and columns would be the same size. If there is too much variation in size, it won't look as nice because we'd size for the maximum allowed and smaller images would look too small in their cells. Unless we scale, which would make you download more data than you'd see, defeating the purpose.