What feature would you like on EQTC.

[Krazick]

My statement:

Well, color coding to distinguish categories of information might on the surface sound like a wonderful idea. However, it is a bad idea from a web perspective to encode useful information.

is based upon W3C Web Compatibility Guidelines. Note:

W3C Compatibility Guidline # 1

primarily

1.8 [E4] [color vision is not required to perceive content (or something like this to allow color-coding issues to exist at extended checkpoint level)]

Yes... you can encode content based on color... but to prevent color impaired readers from struggling to preceive the content... much less black and white printouts... it becomes a major pain. I don't want to make a suggest a precedent setting here that would suggest that we will do this sort of thing in the future. I don't like the idea. I don't want to do it that way.

I will go so far as to state that there are a number of places where color is used to highlight some features of the site (the side menu-bars and their sub-menus... the "red (Trivial 335)" bits... but generally the use of color on the site is more to supplement and artistically enhance the provided information, rather than add meaningful content.

Given the fact that many people would like to be able to print out the information. And they very likely will print out on a black and white printer... it should be useable/precievable from that type of printout.

[Kaz]

[QUOTE=Krazick]My statement:

> Yes... you can encode content based on color... but to prevent color
> impaired readers from struggling to preceive the content... much less black
> and white printouts... it becomes a major pain. I don't want to make a
> suggest a precedent setting here that would suggest that we will do this
> sort of thing in the future. I don't like the idea. I don't want to do it that
> way.

See, that's just a scary degree of political correctness there, way too nineties for me. Of course W3C is a bureaucracy, thus they're insanely PC, but that doesn't mean we all have to follow suit.

This is what I explain to any client who's worried about only basing the site on what people with text reading non-javascript monochrome browsers can handle perfectly:

In your effort to make sure you include the final 0.01%, you are excluding the other 99.9% who would benefit from the improved interface. You actually cause more net harm than good, alienating more users than you benefit.

The percentage of people coming to this site who're color blind is undoubtedly microscopic, or smaller. The percentage who use monochrome printers is probably pretty ****ed small, too, since you can buy a color printer for about $89 without too much shopping around.

But all of that is really irrelevent to this debate, anyway, because here is the huge, gaping problem with what you're saying:

If color coding of ingredient sources were implemented, color blind and antique printer people WOULD LOSE NOTHING.

Why?

Because right now you have NO system for quickly identifying source. Adding a system based on color coding, which would be simpler than ANY other solution (such as adding a graphic showing the source by every item, or trying to find enough variations of bold/italic/strikethrough/upside-down) would therefore deprive nobody of anything, meanwhile it would provide a vital feature to the 99.9% who are not completely colorblind, including people who have ancient printers but can at least see the data on their monitor.

> I will go so far as to state that there are a number of places where color is
> used to highlight some features of the site (the side menu-bars and their
> sub-menus... the "red (Trivial 335)" bits... but generally the use of color on
> the site is more to supplement and artistically enhance the provided
> information, rather than add meaningful content.

This, of course reduces the developer's ability to produce an interface that is heuristic/intuitive and easy to navigate for the 99.9%.

It reminds me of silly people who say we should have universal health care, and cite examples of countries where the health care is indeed universal...and where a painful, life-threatening illness therefore can have an 18 month waiting period for treatment.

> Given the fact that many people would like to be able to print out the
> information. And they very likely will print out on a black and white
> printer... it should be useable/precievable from that type of printout.[

Doesn't the site already have links to printer-friendly versions of pages, like so many other sites do? That would make more sense than limiting the interface utility for the overwhelming majority of people who have at least partial color vision.

[Kaz]

This is not a request for something to be allowed to the general public, but an extension of an idea I had a while back.

I don't know what your tables look like but it seems to me that with the aid of some serious pharmaceuticals you could hallucinate a REALLY nasty query to automatically find "profitable" combines and forward the info off to whoever is the tradeskill contact of the week for Sony.

I probably don't have strong enough mushrooms though.

Why would anyone want to TELL Sony about a profitable tradeskill combine? Don't they do enough such anti-creativity nerfing already? Heaven forfend you feign death during a solo fight and then the mob dies, or find a bow that can be sold back to the vendor for a couple platinum profit, et cetera...

[Dunthor Warsmith]

Why would anyone want to TELL Sony about a profitable tradeskill combine?

One answer would be for the sake of the economy. Profitable, vendor-based combines have proven easily macroable, thus leading to huge platinum influxes. It drives up bazaar prices and increases the divide between the haves and have-nots.

[Ngreth Thergn]

OK, yes I *Could* do it.

And yes it WOULD take a reference to 2 other tables (not just one).
I unfortunatley coded for MySQL 3 which is NOT relational, so I had to create map tables, and this would require a map table to hit the correct spot in the second table. (You say why... because the server originally only had MySql 3... not 4. The server had 4 right when I released... darnit... and the recoding it would take to make it relational would be huge)

Second issue, is as krazic said, when an item has more than one type of source. Which do I choose. **YOU** say choose the vendor source, but druid, ranger, wood elf, and iksar (and probably others) say... choose the foraged source. While yet even others will say I am only interested in drops... which do I mark it for? Again... I refuse to have cookies keep track of which you prefer. Whe could use extra "markers" ($ for vendor, * for foraged, ^ for dropped, etc) but see my third issue bellow.

Third issue is information overload. There is already a HUGE amount of information on that page. Sure *YOU* can take more information, to MANY others (more than the "1%" with color blindness problems) it becomes very confusing, especially if we use marker characters. If we use colors it is not as bad, but you have the problem of my second issue, unless we use a huge color pallet, in which case we are back to information overload.

I will consider it some more.

[bugfinder]

One thing Id like is a pdf or something of all the recipies, which you can generate with PHP btw.. so you could automate it. Maybe do it on a per tradeskill basis, or just 1 huge one..

[Ngreth Thergn]

I will never make anything that makes it easier on other sites to steal the content that we and our members have made.

So there will never be a complete listing available in one source.

Not 5 minutes after we put such a thing, there will be people selling guides from our information on player auctions and ebay.

[bugfinder]

True but only a fool would buy something thats potentially out of date and available for free here :P

It is a shame though I wish I could view a lot of it without the aid of the site while bumbling about in my EQ ways.

You asked for our wishes, it was mine, I have no expectations for delivery because you guys do a rocking job, and you do it without guarenteed payment.

[Ngreth Thergn]

Sorry if I sounded snippy

I get asked for this regularly in various formats The answer will continue to be the same.

The other problem is bandwidth. People will NOT hit this just once... and the download will be HUGE.... people use MUCH less bandwith searching for what specifically they are looking for

[bugfinder]

Na you dont sound snippy, you're an ogre

Like everything theres pros and cons, and it sounds like you've weighed it up.

Only other suggestion is maybe on top of the tree of the recipie would be to add where to buy options, so

* grapes(3)
* wine yeast
* soda water
* champagne magnum

Each of those is clickable with where to buy if possible, currently you expand if made, maybe expand where to buy any of the components, or forage or drops so people can say

"Hey, I fancy making..... brut champagne, I need to... get me a chanter for the gold, buy the gold, get a bottle, get the soda, grapes, hey I can do all this in PoK bargin.. /ooc Hey would a chanter mind doing me some gold enchanting??

and make the item

would be a fair bit of work though I suppose

Reading back someone suggested putting say a * after vendor bought etc.. actually adding that to the query wouldnt be so hard.. each itme would just need a flag on it saying v,d,f, (vendor, drop, forage, crafted) you just pick that up as well as the name of the item from the table

[Sanna]

*afeared*

"maybe expand where to buy any of the components, or forage or drops"

The thing about including all of that information in that click-drop-down list... ALL of that information is loaded when the page loads. That's why Ngreth Sir put in the "subcombines not shown" tag, or whatever the wording ended up being. It's a stop-point for the server to say, "ok, not loading anymore info below this point." When you load that info, per page load, it takes BW. When you /don't/ load that info, it /saves/ BW.

Inserting all, or even some, of the info you suggested, would skyrocket BW usage. Plus it just sounds /scary/ to code.

Yes, I'm just another prole saying this, but still.... *shudderwince*. Clicking a link to find further info hurts far less than always including info which would be useful to /some/ people /some/ of the time, but not /everyone always/.



I still raise my hand and vote for "ability to search for unknown info." I realize I'm (re)saying this on the day OoW comes out, so this place is gonna be a madhouse for a while, so please don't think I'm trying to put temporal pressure on this or anything.... but if the whole Tyking-thing about adding EQIDs to the pages, and making a hidden backsystem to allow Tyking to put recipes in-game is still something that ever wants to be thought about.... then the ability [for some people?] to search for what's missing data in a given slot would be very helpful.

once again, i wish i knew how to code stuff... would make me feel less like I might be asking for something really hard and just don't know.



good luck, everyone, with fielding OoW info. ^_^

-- Sanna

[Ngreth Thergn]

Yeah, unfortunatly everything has to LOAD even if I do not show you.

and some things... like "water flask" the extra info would be gargantuan... (I could add more exceptions... but there is an aditional layer of code and/or queries on an already very busy page.)

[Tweedledea]

Not sure if this has been suggested (long thread...)

It would be helpful if when you searched the database if trivials could be shown next to the items, similar to the recipe lists - and if possible to be able to sort them.

For example: say I have a bunch of serrated arrowheads and I want to know how far I can skill up with them. First instinct is to search - this gives me all the arrows I can make but, doh! it doesn't show the trivials until you click them one by one. So I realise what I should have done was go to the GoD fletching section - this gives me a list I can sort by trivial - but it includes a bunch of arrows made with discord arrowheads, which, for the sake of argument, I'm not interested in because I can't obtain, not being KT flagged. Quick trivial list works, but has a load of entries no longer useful to the, say, 220ish fletcher.

*Pauses for punctuation. None materialises. /Sigh... oh well*

Anyway, I hope you get the idea. It's nice to have a small, practical list to work with, so I prefer to search, but it'd be great to have maybe just a teensy shiny knob and/or whistle added to the search if possible!

Thanks for all the work on the site, and I understand if you don't get to look into this one for a while!

[Ngreth Thergn]

Well... the problem being that that search only hits the items table (not hte recipie table.) and it would take twice as many hits to get the trivial... I will think on it.

[Dunthor Warsmith]

Going to Serrated Arrowhead and then "Find Recipes that use this item", it does generate a list of recipes with trivials present, though its not sortable by trivial.

Other than the sorting aspect, is that what you'd be looking for?

I know I've sometimes been looking for a "class" of item (say, GoD 34/28 weapons) and there isn't much of a way to do that ("Velium Gemmed" includes others, GoD Weapons includes others, etc) but it seems like searching for a class would be difficult to implement. That might be what you were getting at, rather than the "Find Recipes" aspect. If so, I have no idea for a workaround.