23 replies to this topic

[wingshot]

The implementation of tagging in IP.Downloads is great and much need for my site. (My site is very file intensive. 5,000+ files, 50 new members a day downloading them, and the message boards just support the files and associated software)

I added the ability to have parent and child tags (a tag hierarchy). And I included a tag browser on the IP.Downloads main screen (Downloads Portal) so you can actually view resources by tag easier. You have a category view on IP.Downloads. Should I be so bold as to say this should be stock functionality? Maybe not, I guess most people run message boards with files section. I run a files section with a message board.

I did not modify a single line of PHP code. I do have some skin css edits. The rest of my modifications went into a IP.Content block that I call from IP.Downloads portal skin.

I did add a table to the IPBoard database (very unique name so Invision will never overwrite it). This database holds the tag parent-child relationships. Since I haven't changed any php code, or altered IPBoard's core_tag table, this will be like upgrading any other IP.Content block I have during an IPB upgrade. Or I can abandon it all together if Invision introduces this functionality.

The end result is a tag browser that supports parent-child tags, collapsible "tag categories", consistent with the rest of IP.Downloads:

 downloads_tag_browser.png   67.2K   12 downloads
I have some final tweaking to do, but proof of concept looks nicely.

[John Stuart-Clarke]

I think this is great and I would certainly like to see it baked in. I run a nature photography community and I have just made tags mandatory. Being able to browse images and critique topics in this way would be immensely useful to us (and I don't use files - yet - our site is mainly IPB & IPG)

[Marcher Technologies]

The implementation of tagging in IP.Downloads is great and much need for my site. (My site is very file intensive. 5,000+ files, 50 new members a day downloading them, and the message boards just support the files and associated software)

I added the ability to have parent and child tags (a tag hierarchy). And I included a tag browser on the IP.Downloads main screen (Downloads Portal) so you can actually view resources by tag easier. You have a category view on IP.Downloads. Should I be so bold as to say this should be stock functionality? Maybe not, I guess most people run message boards with files section. I run a files section with a message board.

I did not modify a single line of PHP code. I do have some skin css edits. The rest of my modifications went into a IP.Content block that I call from IP.Downloads portal skin.

I did add a table to the IPBoard database (very unique name so Invision will never overwrite it). This database holds the tag parent-child relationships. Since I haven't changed any php code, or altered IPBoard's core_tag table, this will be like upgrading any other IP.Content block I have during an IPB upgrade. Or I can abandon it all together if Invision introduces this functionality.

The end result is a tag browser that supports parent-child tags, collapsible "tag categories", consistent with the rest of IP.Downloads:

 downloads_tag_browser.png   67.2K   12 downloads
I have some final tweaking to do, but proof of concept looks nicely.

just a question.
How, if i may be so bold, are you generating the results sans php?
I assume clicking a tag brings results within downloads like categories do... if it just goes to the search system, I think I fail to see the point.

[wingshot]

just a question.
How, if i may be so bold, are you generating the results sans php?
I assume clicking a tag brings results within downloads like categories do... if it just goes to the search system, I think I fail to see the point.

What's the point of the category listings in IP.Downloads portal? So people can see your categories and the files in each category, right? Convenience, ease of use...You could have a downloads with no category listing on the main page, sure. But there's a reason why we do. The user would have to find a file, then click the category breadcrumb to see the category. That's not very user friendly.

Similarly: The point of having a "Tag Browser" is so users can see the tags. (The point of having the tags in a hierarchy is so you don't have 120 tags (in my case) eating up all the vertical space. The hierarchy also helps people find them easier.)

The only other way a user can see a tag is find a file and click the tag to see all other files with the same tag. Nothing wrong with that. But having a Tag Browser lets a user see your tags to help refine their selection. Remember: tags categorize files more specifically than categories can because you can have multiple tags for a single resource. Having your tags listed this way, helps users find what they are looking for a whole lot easier.

Next up: A tag cloud for IP.Downloads. Seems relatively easy to do too.

[Marcher Technologies]

What's the point of the category listings in IP.Downloads portal? So people can see your categories and the files in each category, right? Convenience, ease of use...You could have a downloads with no category listing on the main page, sure. But there's a reason why we do.

Similarly: The point of having a "Tag Browser" is so users can see the tags. (The point of having the tags in a hierarchy is so you don't have 120 tags (in my case) eating up all the vertical space. The hierarchy also helps people find them easier.)

The only other way a user can see a tag is find a file and click the tag to see all other files with the same tag. Nothing wrong with that. But having a Tag Browser lets a user see your tags to help refine their selection.

Next up: A tag cloud for IP.Downloads. Seems relatively easy to do too.

my point was this.... and you never answered.... which makes me suspect its not staying in IDM
How does "Replacing" The Categories that browses within downloads with tags that push the user to the search system.... help?
How is that a tag browser, per-se?
Is the results within downloads?
id be interested in a link to function.
slipping in some code to form the tag links isn't difficult... but if you are pushing it into search its... not a replacement for categories.

[wingshot]

I don't understand your question. I haven't replaced my categories. help?


Now your editing your post...

I'm still not really clear on what your asking. I think you suspect I made some core change to Downloads. This was a pretty easy change. Content block to IP.Downloads. Insert DB table to track relationships between tags (parent-child) to form hierarchy. I call this a "tag browser". I hope I didn't invoke a sacred term that means something different to other people. For me a tag browser just lets you click a tag...and then see the files that belong to that tag.

Edited by wingshot, 12 December 2011 - 01:57 PM.

[Marcher Technologies]

I don't understand your question. I haven't replaced my categories. help?

look above.
if the uppermost navigation on the page are tags that link to the search system.
you basically making your primary navigation the search function rather than the IDM structure....
keeping people clicking back and forth between the two like that seems counter-intuitive.
The first navigation people use is usually the first they see.
i ask, yet again, whether this does link to search...
If it does, its literally not a tag browser.
it would vanish when a tag is clicked...
hence me wondering how exactly you've done this.

[wingshot]

look above.
if the uppermost navigation on the page are tags that link to the search system.
you basically making your primary navigation the search function rather than the IDM structure....
keeping people clicking back and forth between the two like that seems counter-intuitive.
The first navigation people use is usually the first they see.
i ask, yet again, whether this does link to search...
If it does, its literally not a tag browser.

You keep "asking yet again" and the tone really starts to sound rude. Please see my edited reply above...

[wingshot]

And my so called tag browser, also pulls all tags from IPBoard... Now you can school me on what a tag browser really is, I suppose. For us, the way we think, it's a tag browser because it pulls the tags from IPB and lets the you see which files belong to each tag.

[Marcher Technologies]

What's the point of the category listings in IP.Downloads portal? So people can see your categories and the files in each category, right? Convenience, ease of use...You could have a downloads with no category listing on the main page, sure. But there's a reason why we do. The user would have to find a file, then click the category breadcrumb to see the category. That's not very user friendly.

Similarly: The point of having a "Tag Browser" is so users can see the tags. (The point of having the tags in a hierarchy is so you don't have 120 tags (in my case) eating up all the vertical space. The hierarchy also helps people find them easier.)

The only other way a user can see a tag is find a file and click the tag to see all other files with the same tag. Nothing wrong with that. But having a Tag Browser lets a user see your tags to help refine their selection. Remember: tags categorize files more specifically than categories can because you can have multiple tags for a single resource. Having your tags listed this way, helps users find what they are looking for a whole lot easier.

Next up: A tag cloud for IP.Downloads. Seems relatively easy to do too.

You keep "asking yet again" and the tone really starts to sound rude. Please see my edited reply above...

Sigh. I'm not trying to be rude.
How is it more convenient and easier to use if you are pushing the user into the search system repeatedly?
I LIKE the concept.
no doubt.
but pushing them into a whole other area of the site is not user-friendly either, whereby your whole tag browser and the categories disappear...
why i asked, politely, if results were inline.
if not, do you let guests search?
what about those that Don't?
Google 403 much?

[wingshot]

but pushing them into a whole other area of the site is not user-friendly either, whereby your whole tag browser and the categories disappear...
why i asked.

There we go, plain English . I'm with ya now!

You're right, technically it does push the user into the search system. But that's not some far distant land. Search is very well integrated with IPBoard Downloads. The only real difference is the tag browser is not present on the search page.

When a user clicks a tag, they see this:
 tag_search.png   105.25K   10 downloads

VS This for a category display. I fail to see how this is not user friendly? School me...

 downloads_categories.png   102.79K   2 downloads

You also have to remember. Most of my users start with a search anyway for files. But yes, if IPBoard were to implement this, i would expect the Tag Browser to remain on the left side of the page (as categories presently does).

Just thinking on the fly and outloud, I think a skin edit to the search results page could put the tag browser block on that page if the search is for a tag. Not sure, hafta think on it.

[Dmacleo]

I was wondering if a block there would stop the driving to search system, search once and block shows results and stays.

[wingshot]

I was wondering if a block there would stop the driving to search system, search once and block shows results and stays.

Interesting.. An IP.Content block? How would search results stay and what screen what they stay on?

[Marcher Technologies]

I was wondering if a block there would stop the driving to search system, search once and block shows results and stays.

I was wondering if this could be package-able, and with the above TBH.... ive written some doozies in terms of blocks... wondering about the overhead?

[Marcher Technologies]

Interesting.. An IP.Content block? How would search results stay and what screen what they stay on?

As i said above...
raw php blocks can scare the bleed-all in terms of just WHAT can be done....
the same screen that's the beauty... there's no inner to the landing itself at the same furl.
im thinking a hook would do better though.
your likely gonna need room for functions/classes....
maybe pull the search class in itself?
I know actually querying for the results on a querystring is killer resource overhead >.<
Been there.
Done that.
Fail.

[wingshot]

I was wondering if this could be package-able, and with the above TBH.... ive written some doozies in terms of blocks... wondering about the overhead?

That'd be cool, if it could be package-able, especially if you could keep the results somehow on the downloads page. What I've done isn't packagable at all.

[Dmacleo]

^^
yeah what he said

I don't know enough about it to describe it but I think Marcher described what I was thinking.
like on ipcontent stock install pages, there are blocks that stay when browsing articles or the blogs have similar blocks.

[wingshot]

^^
yeah what he said

I don't know enough about it to describe it but I think Marcher described what I was thinking.
like on ipcontent stock install pages, there are blocks that stay when browsing articles or the blogs have similar blocks.

Ahh plain English again. That's over my head on how you would achieve that in IP.Downloads. I'd buy a mod in a heartbeat if it supported a hiearchy of tags and results on the same page as the Tag Browser. I'd also buy a tag cloud for IP.Downloads. Odd, when I mentioned this to individual modders (not Marcher but others), people acted like these types of mods wouldn't sell and wasn't worth their time. Hence I went my own way...

[Dmacleo]

not sure either, but I think its probably not hard for an experienced person.

as a rudimentary patch can you just add a parseblock statement for that block in all the download portal pages and not just on the actual portal?
wouldn't that cause it to stay?

[Marcher Technologies]

not sure either, but I think its probably not hard for an experienced person.

as a rudimentary patch can you just add a parseblock statement for that block in all the download portal pages and not just on the actual portal?
wouldn't that cause it to stay?

the issue, is and always has been IMHO, that search is subsidized in on itself... TAGS being that way, eg tied into that single place, app and section/module wise, to me is doubly frustrating.
....You OBVIOUSLY have more CONTROL of the data and return within the APP itself.
this is the one item IPC is the Only one to do right, but it still doesn't go FAR enough sans massive shenanigans (IE, not Stock), IMHO.
And.... i'm sorry, but .ipsFilterbar is the biggest joke... it Sorts.... doesn't Filter as a result....
additionally, many of the bugs to do with the search system, are simply caused as an innate result of the inherent difficulties of tying multiple non-native app data to the search system in entirety....
why not use the natural data inline? why make it so hawd ? why take the user AWAY from the app?