Wedge

Public area => The Pub => Features => Topic started by: NeobeatIKK on May 19th, 2012, 12:28 AM

Title: Aeme features ideas.
Post by: NeobeatIKK on May 19th, 2012, 12:28 AM

I have a few ideas to improve Aeme:

It would be nice if:
- Albums can have tags, and items inherit the album tags. That way you don't have to tag each item.
- Albums can have comments at the end. Just like items.

Title: Re: Aeme features.
Post by: Arantor on May 19th, 2012, 01:14 AM

Why would you give comments to an album, out of interest?

I can see the logic of album-level default tags but I'm not sure it would be that useful. (FWIW, I don't recall it ever being asked for before)

What would you use these things for? (I'm not interested in how hypothetically these might be useful to the community at least, I'm interested in how, assuming you had the facility, how exactly you would use them. How you intend to use a feature specifically is a different thing to explaining its benefit generically. ;))

Title: Re: Aeme features.
Post by: NeobeatIKK on May 19th, 2012, 04:39 AM

Sorry I didn't give examples to figure it out.

Well, you upload a bunch of "party photos" from last night, let's say 40 (random number) photos, you know a lot of these photos will share a lot of tags. If these items can inherit tags from its album, you can refine and edit the necessary tags for each photo, it would be nice.

As for the album comments, well is pretty the same idea, if a user don't want to comment in the first item to comment about the entire album or giving an overall comment, that's the album comments for.

I think those would be the benefits... Still, they can be used for more purposes.

Title: Re: Aeme features.
Post by: nend on May 19th, 2012, 04:48 AM

How about playlist that work all the way.

Playlist work fine only for uploaded content. I tried making playlist for embed content and for some reason it doesn't work. I haven't tried in a while or haven't looked in the sources in that section but something there is a miss. I keep forget to bring it up, I don't know if the bug is present here though. :sob:

Getting off topic here, this may belong in the support boards at Aeva. :whistle:

Title: Re: Aeme features.
Post by: Arantor on May 19th, 2012, 05:00 AM

Quote

Well, you upload a bunch of "party photos" from last night, let's say 40 (random number) photos, you know a lot of these photos will share a lot of tags. If these items can inherit tags from its album, you can refine and edit the necessary tags for each photo, it would be nice.

So that's exactly how you're planning to use it? Why bother tagging so many photos with the same tags if you're only going to change them again after?

Please listen to me at this point, it's important. What you've posted sounds like you're trying to give me a general example. I need specific use cases. Trying to argue that a feature should be implemented through a contrived example does not ever work.

Give me an *example* that you've actually come across where it would have helped, since that's what I asked for, not a contrived and semi-made-up example.


Re playlist, I have never tried it, no idea how it's supposed to work.

Title: Re: Aeme features.
Post by: NeobeatIKK on May 19th, 2012, 05:14 AM

Ok, In my actual forum I have Media with a lot of videogame content, when I upload a photo album (Guilty Gear for a real example) I know a lot of these items share the same tags (Guilty Gear, Dreamcast, Fighting, gaming, videogames, weapons), and if when some items need more explicit tags (for characters and other things) I would only need to add a few tags (Ky, Sol... character names or scenarios.)
Most of cases you don't need to edit tags item by item.

As for the album comment, if you want to say "wow I love this artbook", you can't say that it in the first item, it would be more accurate to have it an album comment.

I'm not saying you have to implement those ideas (I don't have that right,) but it would be nice to see them in the latest version of Aeme for a chance. :)

Title: Re: Aeme features ideas.
Post by: nolsilang on May 19th, 2012, 06:12 AM

So it's like album comment and picture comment on facebook? You can comment on album or per picture.

Title: Re: Aeme features ideas.
Post by: Arantor on May 19th, 2012, 03:44 PM

You see, now you've given me a specific example of use, I can actually understand the point of it.

Part of the problem with FB is that you actually can't always tell if you're commenting on the album or a picture in it (and half the time it seems to conflate the two for you anyway)

I have to say I'm not entirely sure how much use comments on an album might be at this stage but it's certainly an interesting idea.

Title: Re: Aeme features ideas.
Post by: Nao on May 19th, 2012, 05:34 PM

Album comments is one of the features that had been in AeMe's to-do-list for years...
I never got around to implementing them.

One of my goals with floating boards, is to make it relatively easier to implement this kind of thing.
Let's just say that board #355 is of type 'album' (or whatever), internally associated to album #421, and has topic #7234 associated to media item #6212. (We really should add a meta_id field to the topic table where we could store this kind of relationship data...)
So, every time you want to post a general comment in the album #421, that means posting a message in topic #7122 which is in board #355 and has a meta_id of #0, meaning "album comment"...
(It may sound a bit weird, but that's pretty much the only possible way to implement floating boards without breaking the auto-incrementing aspect of topic IDs...)

I'd love opinions on this implementation concept!

A temporary workaround would also be to show in the album homepage a list of the most recent comments for any items within the album. At least, that could be implemented right now... It doesn't solve the "where do I post if I don't want to comment on anything special?" issue, though...

Title: Re: Aeme features ideas.
Post by: Arantor on May 19th, 2012, 06:02 PM

I'd rather break auto incrementation than make the system convoluted, personally. Auto incrementation does not bother me in the scheme of things, making it harder to use, harder to support and harder to extend does bother me a lot though.

(FWIW, it doesn't even bother me that board 2 is currently the recycle bin by default)

Title: Re: Aeme features ideas.
Post by: NeobeatIKK on May 19th, 2012, 06:33 PM

Quote from Nao on May 19th, 2012, 05:34 PM

A temporary workaround would also be to show in the album homepage a list of the most recent comments for any items within the album. At least, that could be implemented right now... It doesn't solve the "where do I post if I don't want to comment on anything special?" issue, though...

That's a very nice idea too, and yes that was my problem... When my users needed to comment about the entire album they had to comment in the first album item. But the recent comments view should work well too.

Title: Re: Aeme features ideas.
Post by: Nao on May 19th, 2012, 07:43 PM

I don't see why it would be harder to extend.
Also, getting rid of auto increment forces us to specify the board type in the URL and do the main index on (id_topic, board_type)... Not sure it'd be very efficient?

Title: Re: Aeme features ideas.
Post by: Arantor on May 19th, 2012, 08:31 PM

Let me put it this way, I read your description several times and I was still left confused as to how to query it.

Why would you have to have the board type in the URL? See, I'm thinking about the last time we talked about this, where you wanted to have things so that board 2 was the second real board and that the recycle bin was somewhere else - the same core problem is applicable here.

In the way I'd see it, an album is an entry in the boards table, then a media item just exists as a new 'topic'. Thus you lose the continuity of ids but you don't lose any ids, per se.

Title: Re: Aeme features ideas.
Post by: Nao on May 19th, 2012, 08:37 PM

Iunderstand your pov but you're probably forgetting about forum imports. We could get away with it by importing all albums and items into the topic table as new items but then we lose the date posted/id relationship. If you sort topics by date you get old items at the top of the list. I had this problem with my blog when I imported it into noisen. I had to fix it by sorting by time instead of id... Meh!

Title: Re: Aeme features ideas.
Post by: Arantor on May 19th, 2012, 08:41 PM

Hmm, yeah, there are benefits to sorting by id, too :/

Title: Re: Aeme features ideas.
Post by: Nao on May 19th, 2012, 11:21 PM

Any smart suggestions then...?

Of course even with a dual index on I'd_board we can't avoid sorting by time rather than by id. Tbh I really chose this path Brcause I didn't want to bother too much with importing data... But were still gonna have to do it anyway.

Doctor Who night tonight on channel France 14.  5 reruns of seasons 2005 and 2011 and first runs of Genesis of the Daleks, Edge of Destruction and City of Death. Yay!!

Posted: May 19th, 2012, 09:09 PM

Only way to sort by Id is to filter by board type and only show one at a time...

Posted: May 19th, 2012, 09:11 PM

Bump...?

(So, do we add an index on poster_time, maybe...?)

Title: Re: Aeme features ideas.
Post by: Arantor on May 19th, 2012, 11:35 PM

I don't know... there are serious benefits to ordering by physical id but note that I'm not talking about the same thing that you are.

If you filter by id_board + some kind of filter (which I'd make a dual index), you can still sort by id_topic which can be regularly increasing. But it does, as you say, cause trouble for importing just as it can for merging/external importing stuff.

In an ideal world, I'd just sort by time and be done with it but the performance aspects are awkward - InnoDB physically arranges rows by primary key as opposed to MyISAM ordering by creation and where it'll fit in the table - but I don't think we can do much about changing it, I think we're going to have to swallow the penalty of ordering by time, or we don't do this using the boards/topics tables.

Title: Re: Aeme features ideas.
Post by: Nao on May 19th, 2012, 11:48 PM

- Ordering by poster_time means adding an extra key, although in the messages table there's already a surprising amount of keys...

- My main concern with converters is that TE isn't around much these days... Hasn't been online in weeks, hasn't posted in a month. I'd rather have media albums converted to floating boards at import time -- if anything, we can always remove the items from around here, or even do the conversion manually...
So, who writes the converter code, eh eh...

- I suppose it's okay doing everything by id if topics can be filtered by board type... In which case they'll always be sorted correctly.

- I don't even know if it's best to have an album = a board, or a gallery = a board... If an album = a board, then an item = a topic. Let's consider that if a topic is sticky or something, it means it's an album topic, not an item topic. If an album = a topic, then we could have it done this way: any replies = album comment, new items are posted as a special post in these topics, and from within the item page, if you comment on the item, it actually posts a reply to the album topic but it's set to have the item's special post as its PARENT internally... See? A threaded discussion. It's harder to manipulate though (moving items around, deleting them...), but I find the idea amusing.

Title: Re: Aeme features ideas.
Post by: Arantor on May 20th, 2012, 12:15 AM

Well, here's the thing. There's ordering topics by time/date and ordering posts by time/date, the latter certainly would likely be able to be indexed and the query for identifying posts based on that should be comparable with the current query (since the message ids can be found from the index), and requires no changes anywhere to queries other than to change the field we're pointing at.

Now, in the message index, the primary methods of sorting are by first post or last post in a thread (barring sticky), and though there are others, in virtually every case we'll be using those. The problem is that that those fields are not part of the topics table, and that means an extra join that we might need to work into the mix, or juggle the existing (complicated) joins. (And we need to apply this to the join made for the previous/next topics too)

The bottom line is that it will have a performance impact spread across more places - unless we keep the first post's and last post's time in the topics table too (and have an index on there too)


The reason I stepped back on the whole floating-topics idea is because of the debate we had before about having non-contiguous ids, e.g. board 1 is a default board, board 3 is the first user created board, and board 2 can't be used by default by the user - something similar will happen here.

I'd rather make an album as a type of board, because what we're talking about is a container that contains one or more content items - which means making the album's comments into a sticky topic. It does make some of the management complicated, but we can suitably manage that.

Title: Re: Aeme features ideas.
Post by: Nao on May 20th, 2012, 09:21 AM

Re: sorting, I was definitely thinking about adding a poster_time field to the topic table as well, so it'd at least wouldn't require a join just to do the sorting... There aren't that many places where a rewrite is required...?
I didn't think about the last poster time though, sounds like a good idea...
Anyway, the topic table is definitely one of the least polluted in the entire table list. Most of its data is taken from its id_first_msg indeed, but I'm sure we could benefit from moving some of this data into the table.
Heck, I'm sure we could even benefit from moving the subject into the topic... :P Maybe even remove it from the post table but I'm sure some people would kill me for that :lol:

I don't mind using entire boards for an album. I just hope you realize that it'll make the topic table grow way more quickly than if we stored one album per topic :)

Title: Re: Aeme features ideas.
Post by: live627 on May 20th, 2012, 09:33 AM

Quote

Maybe even remove it from the post table but I'm sure some people would kill me for that

it would save a sql join for fringe cases where only the subject is needed from a specific topic.

Title: Re: Aeme features ideas.
Post by: Nao on May 20th, 2012, 10:08 AM

I don't know, I've just never been a big fan of storing subjects when most of the time they're the same as the topic's...
Heck, I don't remember if Wedge stores the subject if it's the same. I think the Noisen codebase stores an empty subject or just 'Re:' in that case, but I'm not sure.

Title: Re: Aeme features ideas.
Post by: Arantor on May 20th, 2012, 03:18 PM

If you move the poster_time into the topics table, you have to do it for both the first and last posts in the topic, and you have to remember to update these when posting, but since you're already doing that to set up the first/last post id that's no biggie. (But we need to keep those too.)

You could only really benefit in moving if you can avoid the join to the messages table in the process, and that's already done in some places anyway. But I'm not a fan of moving the subject there.

While I couldn't care less about the subject being settable per post (and I have used it very sparingly), I do care about the performance impact that will have, as I observed with SimpleDesk; the topics table is fixed width, means it's *very* fast to traverse and look up, especially when you get into the realms of sorting. If you pull non-fixed-width content into that, it starts to hurt, and bear in mind there are several places that makes a difference (message index, display for the topic and prev/next for the topic come to mind)

Quote

I don't mind using entire boards for an album. I just hope you realize that it'll make the topic table grow way more quickly than if we stored one album per topic

Yes - but also, that *all* becomes searchable, for free. I consider that a bonus.

Title: Re: Aeme features ideas.
Post by: Nao on May 20th, 2012, 04:38 PM

Searchable, yes, it's a bonus. Heck it was my main point for going floating actually :P

How about we make the messages table fixed-width, if it's faster? I'm sure we could move non-fixed data to a secondary table :lol:
j/k, although we could use a few minutes of our time to evaluate that ;)

Title: Re: Aeme features ideas.
Post by: Arantor on May 20th, 2012, 04:57 PM

Having two tables with that content in is probably not worth the effort, to be honest.

The big hits on the table, really, are figuring out which messages to show (which is done by evaluating against the primary key in a range, at present) and then loading pretty much entire rows with the primary key.

What I would be in favour of doing is removing the participation index and actually moving that to a discrete table which allows for proper unfollowing in unread replies, for example.