Difference between revisions of "User talk:Lymaniii"

From PinataIsland.info, the Viva Piñata wiki
Jump to: navigation, search
(PV crib sheet)
((Please copy signatures to discussions that you split.))
Line 164: Line 164:
 
:::I appreciate the suggestions, and I'm happy to see that there may be ways of approaching this that would be acceptable. [Sorry I forgot to include a timestamp on this before! [[User:Lymaniii|Lymaniii]] 22:20, 5 May 2009 (UTC)]
 
:::I appreciate the suggestions, and I'm happy to see that there may be ways of approaching this that would be acceptable. [Sorry I forgot to include a timestamp on this before! [[User:Lymaniii|Lymaniii]] 22:20, 5 May 2009 (UTC)]
  
::::Raw image links are unfriendly for a few other reasons, outside of suddenly dropping a person onto a page with no navigation.  First, some of the PV cards are at native resolution from VP.com.  This means if the viewer's resolution can't support an image that's 1024 pixels wide, they'll have no way to easily view a lower resolution.  The wiki page manages that for them, instead of forcing them to save an image and rescale it themselves.  Second, landing pages should be wiki'd because visitors do come here from ''outside'' the site (e.g., links to us from other sites or from search engines).  Also, I have a feeling that Jim would say the "irrelevant" content (e.g., ads) is something he'd want people to consistently see.
+
::::Raw image links are unfriendly for a few other reasons, outside of suddenly dropping a person onto a page with no navigation.  First, some of the PV cards are at native resolution from VP.com.  This means if the viewer's resolution can't support an image that's 1024 pixels wide, they'll have no way to easily view a lower resolution.  The wiki page manages that for them, instead of forcing them to save an image and rescale it themselves.  Second, landing pages should be wiki'd because visitors do come here from ''outside'' the site (e.g., links to us from other sites or from search engines).  Also, I have a feeling that Jim would say the "irrelevant" content (e.g., ads) is something he'd want people to consistently see. --[[User:FeralKitty|FeralKitty]] ([[User_talk:FeralKitty|talk]]) 21:54, 5 May 2009 (UTC)
  
 
:::::I don't know Jim at all, so I don't know what kind of premium he puts on ubiquitous advertising, but in the sites I've managed, more ad spots on a page does not always translate to additional user clicks, and it's therefore unproductive to insist that they are there as a constant first priority.  There are plenty of other options for people to see ads on the site.
 
:::::I don't know Jim at all, so I don't know what kind of premium he puts on ubiquitous advertising, but in the sites I've managed, more ad spots on a page does not always translate to additional user clicks, and it's therefore unproductive to insist that they are there as a constant first priority.  There are plenty of other options for people to see ads on the site.
  
 
:::::As for the image issue, you are probably aware that most current browsers resize images to fit within the viewable window, and this only works automatically if the image is opened *as* an image, not as a part of a page requiring scrolling.[[User:Lymaniii|Lymaniii]] 22:20, 5 May 2009 (UTC)
 
:::::As for the image issue, you are probably aware that most current browsers resize images to fit within the viewable window, and this only works automatically if the image is opened *as* an image, not as a part of a page requiring scrolling.[[User:Lymaniii|Lymaniii]] 22:20, 5 May 2009 (UTC)
 +
 +
::::::I don't think I insisted that ads should be there or that they are a first priority.  Let's not put words in my mouth :)  I'm not going to debate ads since the question simply should be whether links should go to raw images or not.  Yes, I'm also aware that modern browsers can resize images, if enabled, but we shouldn't exclude some percentage of visitors whose images wouldn't be resized.  Perhaps Jim can decide about raw image links, since we're going around in a circle again.  --[[User:FeralKitty|FeralKitty]] ([[User_talk:FeralKitty|talk]]) 22:58, 5 May 2009 (UTC)
  
 
::::IMO, different link behaviors isn't something the visitors should have to deal with, but feel free to take up the "links sometimes go to different places" topic with Jim.  I'll go along with what he decides.
 
::::IMO, different link behaviors isn't something the visitors should have to deal with, but feel free to take up the "links sometimes go to different places" topic with Jim.  I'll go along with what he decides.
  
::::Exceptions based on "we'll do things differently on this page because we have good reasons" ''aren't'' forms of comprehensive and inclusive solutions.  While there's nothing wrong with doing things new ways, or coming up with ways to handle new things, consistency implies that these (old or new) approaches are whole-heartedly uniform '''across the site'''.  Proposing to handle something a new or different or better way should be site-centric, not page-centric.  Frankly, it's hard to clean up a mix of different styles, after the fact, so it helps editors out from having to reword or restyle or relink things things similarly to fit in with the style guide or conventions.
+
::::Exceptions based on "we'll do things differently on this page because we have good reasons" ''aren't'' forms of comprehensive and inclusive solutions.  While there's nothing wrong with doing things new ways, or coming up with ways to handle new things, consistency implies that these (old or new) approaches are whole-heartedly uniform '''across the site'''.  Proposing to handle something a new or different or better way should be site-centric, not page-centric.  Frankly, it's hard to clean up a mix of different styles, after the fact, so it helps editors out from having to reword or restyle or relink things things similarly to fit in with the style guide or conventions. --[[User:FeralKitty|FeralKitty]] ([[User_talk:FeralKitty|talk]]) 21:54, 5 May 2009 (UTC)
  
 
:::::This, of course, is and has been the crux of where we disagree.  Utility and purpose trumps rigidity and dogma.  The purpose of having a site-centric consistency is because it generally facilitates that utility.  When it ceases to do so, you just have to let go.  Whether this is an instance of where this is the case is debatable, but the principle itself is something of which I'm quite certain.[[User:Lymaniii|Lymaniii]] 22:20, 5 May 2009 (UTC)
 
:::::This, of course, is and has been the crux of where we disagree.  Utility and purpose trumps rigidity and dogma.  The purpose of having a site-centric consistency is because it generally facilitates that utility.  When it ceases to do so, you just have to let go.  Whether this is an instance of where this is the case is debatable, but the principle itself is something of which I'm quite certain.[[User:Lymaniii|Lymaniii]] 22:20, 5 May 2009 (UTC)
 +
 +
::::::We disagree because I argue that utility and purpose should work in conjunction with consistency, not independently of it.  Let's just agree to disagree, because I think there's not much new to say, and we're really not getting anywhere at this point.  --[[User:FeralKitty|FeralKitty]] ([[User_talk:FeralKitty|talk]]) 22:58, 5 May 2009 (UTC)
  
 
::::As for "not being possible," ask Jim if he'd install the ImageMap extension for you.  It's the simpler effort for him, although a bit more complicated for you to mark-up inline.  --[[User:FeralKitty|FeralKitty]] ([[User_talk:FeralKitty|talk]]) 21:54, 5 May 2009 (UTC)
 
::::As for "not being possible," ask Jim if he'd install the ImageMap extension for you.  It's the simpler effort for him, although a bit more complicated for you to mark-up inline.  --[[User:FeralKitty|FeralKitty]] ([[User_talk:FeralKitty|talk]]) 21:54, 5 May 2009 (UTC)

Revision as of 14:58, 5 May 2009

Welcome, fellow piñata enthusiast!

Hello, Lymaniii, and welcome to PinataIsland.info! Thank you for your contributions. I hope you like the place and decide to stay. Here are some pages that you might find helpful:

If you're already familiar with wiki editing, feel free to refer to our Site-specific Style guidelines for specific site style conventions.

To include information about your Xbox Live gamertag on your User page add the markup below:

{{Gamertag|XXXXXX}}

Substitute your Gamertag in place of XXXXXX.

I hope you enjoy editing here! Please sign your name on talk pages using four tildes (~~~~); this will automatically produce your name and the date. If you need help, ask me on my talk page. Again, welcome! FeralKitty (talk) 19:41, 18 February 2009 (UTC)

Thanks

The updates and additions that you made are appreciated! --FeralKitty (talk) 19:41, 18 February 2009 (UTC)


Everything but the kitchen sink

It's a familiar concept that bites many of us at times, to creep more features into an application, to add more bells and whistles to some item, to cram more "content" into a wiki article. Being an idealistic person myself, it's easy to imagine having 100% of the details within a wiki article. Having done that, one could also lay that article out so it's viewable at, say, 800x600.

While it's possible to do something, I think the more important question, subjective as it is, is whether or not we should should do something. As an example, let's use the arctic versions and variants, and how I had set out to fit sub-garden species PV cards into the species article sandbox. Certainly, it's species-specific, so the cards are in the right article, and let's say it looks great at any resolution. Do we want to add those images to the article, and its Infobox? Is there a need to cram more visual information in there, to make the Infobox longer, to make the article longer, to give the viewer more information to look at or scroll past? Surely the majority of people come to the species article for the requirements, and the arctic version card is mostly incidental? Images can be worth a thousand words, but in this case, we're not sparing the viewer from thousands of words. I think seven more images bloated the article, and adding a sentence or two would be a better trade-off.

Giving people too much information can lead to other problems. Maybe some viewers are avid or diligent readers, and will take in and appreciate every tidbit of information, but other viewers may overlook what they're searching for, because its buried somewhere in the paragraphs of text and screenful of images. Now, technically, that's not the wiki's fault (since it's supposed to be a reference source of information about the game), and it should be the burden of the visitor to read articles, but experience has shown us that people don't "find" information (that's) at the wiki.

I don't think the solution is to cram more information in, every single place where someone someone might look for or expect it. I think solutions have to do with improving navigation, organization, and presentation. Yes, trick item cards could be added to a challenge article, but then they should be added to the species article too, right? So, we add this in there, and so forth, and the whole thing spirals. It gets harder to search the site, because you get hits all over the place, and it gets harder to maintain the site, because it's got thousands and thousands of images and repeated information in all sorts of different places, and the harder it is to maintain, the less accurate it can become, which interferes with its purpose as a reference. I favor the "keep it simple" philosophy. If it's not broken, it probably shouldn't be fixed, especially if the "fix" is more complex than what existed beforehand.

I guess that's why I get a little leery of adding features like "click on this link to see a PV card for the item to learn a trick," because the mechanism might not be intuitive or obvious to everyone, because it's not consistent across the site (and visitors haven't had to do that before for other images), and because it didn't feel simple (or look ok, back then). To me, the trade-off for trick item cards seems to be between "making the site make it easier for the gamer to earn achievements," versus "making the site easier to use, period."

We're adding cards to make it easier to accomplish 100% of the challenges. Isn't that good enough? I think that the wiki was meant as a reference. Adding trick item cards too just feels like "everything but the kitchen sink," and I don't think we should take articles that far, to cram every possible image into them. --FeralKitty (talk) 22:29, 1 May 2009 (UTC)

We need to get each other's instant messaging IDs so we can chat better! :-) I just left a long comment on the same topic a couple minutes before you posted this (over on the Langston page). I appreciate what you're saying, but it's a stretch to extrapolate from including directly relevant images that, if executed correctly, are completely consistent with a concise and navigable page to the idea that thousands and thousands of images are going to clog up the flow of the site. Lymaniii 23:19, 1 May 2009 (UTC)
This site takes up so much of my time as is. I think discussions work better for me, timeslice-wise. Also, wiki discussions will keep everyone (especially Jim) in the loop, and any member can participate in (or catch up) with article discussions that interest them. --FeralKitty (talk) 00:32, 2 May 2009 (UTC)
Mostly I was joking. It does seem an inefficient way of back-and-forth on something. Especially when it's branched out to different locations.Lymaniii 11:45, 2 May 2009 (UTC)
I'm with you on your explanation of keeping the arctic species details in a separate linked place. That's perfectly reasonable and your rationale makes sense. However, the site *is* broken in the sense of easy navigation, and it does need to be fixed. I have seen many comments from people that *have* searched and scoured and tried to find information that they know is there somewhere, but they're unable to find it. Even BIGsheep has made comments along those lines, more than once. In the case of the arctic tigermisu, a link to the arctic article is good, but a teaser that gives the user some sense that there's interesting information there other than just a list of arctic species is even better. Lymaniii 23:19, 1 May 2009 (UTC)
All we need is a volunteer with the time/motivation to step up and start to deal with any navigation shortcomings. As for things like the artic details, or finding other information, I proposed the "ten things" article as a way to pull together obscure information. None of the things you're mentioning are new. It just takes time and effort to add content or fix issues, and my to-do list has enough stuff on it. Find something you want to work on, and go for it. As long as we're moving forward (solving problems), instead of sideways or backwards (creating other problems), you'll have my approval and gratitude. --FeralKitty (talk) 00:32, 2 May 2009 (UTC)
If I could only predict what you believe moves us forward (as we apparently disagree on that with regularity!). :-) Lymaniii 11:42, 2 May 2009 (UTC)
You seem to have a very specific idea of what makes for good navigation, organization, and presentation, but I'm arguing for the exact same goals with a different idea of what gets us there. You and I can speculate about what people come to the site for and how to make it better suited to that purpose, but what we really need is actual numbers of people that use actual pages, search strings, resolutions, etc. For example, I think we agree that a lot of people just go to the species articles to find out the requirements. But what seems crazy to me is that the TIP and classic species requirements are included on the same page. That makes for *horrible* navigation. And it's unnecessary, really, since the page is really just multiple pages that download together when any individual user only needs one of them. If you want to go from species to species, it takes two clicks since you have to constantly be resetting the tabs. The most prominent search term on the wiki is "pinata vision", but the page that it leads to is a very poorly navigable linear list of many hundreds of text links. If that's the *main* reason people come to the site, surely there's a better way to organize that information (and I don't think progressively longer unabbreviated names is it). Lymaniii 23:19, 1 May 2009 (UTC)
I have no access to logs. If Jim wants to share referrer strings or statistics, you'd have to take that up with him. I hope though that you won't use actual facts to contradict any of my speculations :p
The tabs may make for inconvenient navigation, but the real horror would be splitting every single tabbed article up into a series of articles. You'd have just increased the number of search hits by a factor of 2-5, making it less likely people will find the right page in the results. It also means additional information would have to be duplicated -- instead of answering a question on one page, it would have to be answered on every tab you split off onto a new article.
Frankly, I find the tabs convenient, as it's easier to visually note differences or missing information between tabs within a single article, than different articles' content.
As for the pinata vision deal, there are articles and there are categories, and categories themselves should have their own articles, with catmores to them. If they don't, no one has gotten around to improving them. I can point you in the right direction, if you need an example to follow. Almost every cloud term is a category. Maybe the cloud should filter out (or rewrite) category links, if corresponding articles exist, since category articles are more user-friendly than categories. --FeralKitty (talk) 00:32, 2 May 2009 (UTC)
I recognize that splitting those pages would be a nightmare--it is the real instance of where a particular choice in site design becomes nearly impossible to change (rather than providing a piece of information in two places), and unfortunately this is an instance where it really does matter. While the tabs most certainly make for an easier *author* experience, I can tell you most certainly from my own *user* experience they are a pain. I have finished Classic and no longer need to see those pages, but I am *constantly* being forced back to its pages. Not only that, but the FAQs at the bottom of many pages have answers that apply only to Classic and could easily be giving frankly incorrect impressions to visitors. Now *that's* a problem with site design. Lymaniii 11:45, 2 May 2009 (UTC)
Pointing out site design shortcomings only takes us so far. Do you have any solutions and/or time to implement them? --FeralKitty (talk) 20:33, 2 May 2009 (UTC)
Regardless, I brought up that and the PV list only as examples of how the most used parts of the site are the worst designed. How the category and catmores work is unfamiliar to me. I just know the present state of affairs has great potential for improvement, and that preserving the site's search function and clear navigation as a justification for limiting improvements elsewhere is a bit laughable as there's little to preserve. I'm being frank here, as you have been, and no insults to you or the site owner are intended.Lymaniii 11:45, 2 May 2009 (UTC)
Anyway, I hope I haven't annoyed you by discussing these things with you. Online communication is notorious for fostering misunderstandings, and I sense a certain edginess in some of our exchanges. I realize it's somewhat presumptuous for me to waltz in here rocking the boat when you've invested unnumerable hours in this site on a near daily basis for years. So, thanks for all you do and please accept all of these ideas as they are intended--just to be helpful and improve things.Lymaniii 23:19, 1 May 2009 (UTC)
I don't have the same amount of time, energy, or enthusiasm to tackle some of the bigger issues I used to deal with, myself. There's too much work for one person to do it all, and I'm involved with the forum too, to the wiki's long-standing detriment. I don't care if the boat is rocked, but it does at times get a little tedious going over the same issues, as people come and go. I like ideas -- they stimulate discussions and hopefully lead to ideal solutions -- I think we just need more people to tackle the things that need some attention, as I'm less of a contributor and more of a maintainer, these days. --FeralKitty (talk) 00:32, 2 May 2009 (UTC)


Eliminating tabs

Before we go down this path, do you have the time to fix this?

For the sake of example, let's arbitrarily use the following convention for article names:

  • [[Mousezilla]] (A disambiguation page, with links to each of the other pages. One could also make it a redirect to the most popular game's species, but that's no different than having made Classic the default tab -- the redirect would be fine for, say, Trouble in Paradise gamers, but takes other gamers to the wrong article. On the other hand, taking people to a disambiguation page makes them click one more time, which is no different than taking them to the wrong page.)
  • [[Mousezilla (Trouble in Paradise)]]
  • [[Mousezilla (Trouble in Paradise - Just for Fun)]]
  • [[Mousezilla (Pocket Paradise)]]
  • [[Mousezilla (TV show)]]

For this to fix the "getting to the wrong page" complaint, all other links that refer to [[Mousezilla]] have to be rewritten. If the link is on a game-specific page, say [[Apple tree (Trouble in Paradise)]], then the link gets changed to [[Mousezilla (Trouble in Paradise)]]. What about pages that aren't game-specific? I'd think that they'd have to be split into their own disambiguated pages, and given game-specific links. If you don't do that, then the "wrong page, need to click another tab/link" issue merely has changed from Classic -> Trouble in Paradise to disambiguation -> Trouble in Paradise. So, you'd really have to split all sorts of articles to rewrite links, such as plants, achievements, and shops. (If tabs should be eliminated, I'd imagine it should be site-wide.)

Assuming all the links are rewritten, once you're in Trouble in Paradise article "space," all the rewritten links should keep you there. Now, how do you get/navigate to Trouble in Paradise space in the first place, and how do you navigate from one game space to another, if someone wants/needs to do so? The navigation would need to be completely rewritten. I'd expect that it would make sense to go with a game-centric navigation to match the game-split article paradigm. So split navigation, using current navigation examples, starts to look like:

  • Classic
    • FAQ (Classic)
    • Species (Classic)
    • Tips and Strategies (Classic)
  • Trouble in Paradise
    • FAQ (Trouble in Paradise)
    • Species (Trouble in Paradise)
    • Tips and Strategies (Trouble in Paradise)

Let's assume that is done via drop-down or flyout menus, since one certainly wouldn't want to see that as a list of links. So, someone might have to code and support a new menu system, since I don't think mediawiki supports either type of menu. (I'd love to see new menus and have brought up a top bar suggestion several times, but never got around to working on anything.)

So, given some new proposal and an idea of the changes that would have to be made, do we have people who will make all these changes, taking it through to the end, so the wiki isn't left in a part-changed mix of tabbed and split articles?

What are the reasons for splitting the articles, in the first place? What problems are being fixed, besides the "extra click?" (I'm not sure it's possible to eliminate all extra clicks; wouldn't we just be introducing a different extra click, via the disambiguation or navigation? Are we fixing a problem, or did we move sideways?)

What are some of the advantages or disadvantages of doing this? For me, the biggest concern has to do with searching. Does this make it easier to find information? Well, on the topic of searching this new split-article wiki, let's assume someone searches for Mousezilla. The nature of the default wiki search is that if there's an article with that title, they'll be taken directly to that article, instead of being shown all hits. So, they're going to land on the Mousezilla disambiguation page, and have to make an extra click. (Even if results were shown, they still have to make an extra click on the search result link that they choose to visit.)

Let's assume results were shown (either because they clicked on Search instead of Go, or because no named article existed, so occurrences were shown). In a split-article wiki, you get hits from every split article, so they'd have 2-5 times the number of search results. Considering the complaints about searching, I wouldn't think it would be an improvement to generate more results, would it?

To answer your question here, I see moving forward as a solution that solves a problem without making another problem worse. Like you often point out, the wiki has things that need fixing. I think everyone would like to see them fixed, so let's look for ways that eliminate problems. If there's a way to do that by splitting articles as you suggest, I'm interested. --FeralKitty (talk) 20:33, 2 May 2009 (UTC)

Thanks for that thorough response including a number of technical issues related. I don't think there's a feasible way to make changes that would solve the problem without excessive effort, and I don't think anyone has the time or will for that. As a side comment, while search is important, the scope of the wiki isn't so large that search is as necessary as it is for other wikis. Basically, providing a more thorough site map may be more helpful than trying to hedge up the accuracy of search results. Anyway, I've been mulling all these things, because I recognize that criticisms without solutions aren't helpful. My own preferred way to improve the site is to create a new page that includes a brief summary of the most commonly sought information. I looked into it a bit today, and I'll try to work something up for you to have a look at. I do apologize for letting my exasperation show in my comments earlier today (here and elsewhere), but the issues we were discussing are widely relevant, not just to the specific issue then at hand. If you don't like the idea of pages that serve a purpose that is served elsewhere, there's no future for the page I have in mind. Basically, I imagine the existing species pages as remaining the 'comprehensive' article on that species, and it's appropriate that it have the verbiage from the game, etc. But I believe many, perhaps most, people open the site as they're playing the game so they can find the requirements they need for whatever they are trying to accomplish, and that need moves rapidly from species to species. I imagine it would have been wonderful to have a table of all the species and their requirements (similar to walkthroughs I've seen on other sites) including links to PV cards. Because the bulk of the hundreds of PV cards could be linked from such a grid, it would both organize those cards and provide a summary list of requirements that wouldn't require flipping from species page to species page (and tab to tab). So, I'll work on that. And don't rule it out til you see it, please. I see it as a "workaround" for reworking all the pages as you've discussed, and I sense that you are loathe to employ workarounds.  :-) But I genuinely think it will help, and it is an achievable task. Lymaniii 23:12, 2 May 2009 (UTC)

PV crib sheet

I started creating the table I mentioned previously. It is on my user page (since I don't know how to create subpages as sandbox pages, or whatever). I put the requirements into an excel spreadsheet and then used concatenate functions to build the wiki syntax to link to the appropriate PV card. Trouble is that the naming conventions frequently aren't followed and when there are two types of items in a column, the naming convention doesn't lend itself to a single concatenate formula (e.g. creating the filename string for a chili takes a different equation than for a bunnycomb, even though they are both items included in the trick column. So, my questions are:

  • Is this a page you would allow to exist?
  • What is the best way to address the naming problems--fix the files' names or make the link match the existing incorrect name? Both are a little labor intensive, but it seems best to go with the former. On the other hand, that also means updating all the individual species pages that are linking to the files that have an incorrect name. Maybe there's some nice wiki feature that will update linking references automatically when you update a particular image and replace it with a new image with a new filename? [hoping, although assuming nothing could possibly be that easy]
  • I recognize that this doesn't follow the convention elsewhere on the site where these words would lead to an article page rather than an image. But, I would submit that as a unique individual page it could note at the outset that all links within the table are to PV images (as that is the purpose of the page, with a secondary purpose being a shortened cheat list of requirements). Given this irregularity, would you tolerate this sort of departure?Lymaniii 00:56, 3 May 2009 (UTC)
If you want to make a user subpage, you can glance at my or ImaTest's user page and see examples. If you want it to be called PV crib sheet, just edit User:Lymaniii/PV crib sheet. If naming conventions weren't followed, please just link to the current misnamed image. I'm not aware of an option to update image links, if filenames change. There may be a bot that does that, but you'd have to ask Jim about that, since it would be server-side. Speaking about names, you may want to consider BluebellSeed-TroubleInParadise-PV.jpg instead of Bluebell-seed-TroubleInParadise-PV-jpg, to stick with the name-game format, which keeps the game in the second field.
Would I "allow this page" or "tolerate this sort of departure?" I probably wouldn't tolerate repeatedly being asked if I'd tolerate things. :p Besides, it's a user page, and user pages are personal articles that are considered separate from the main wiki. There really aren't guidelines or conventions for them (and you won't tend to find main pages linking to them). I don't have any problems with your creativity, or thinking outside the box, and I'm interested in seeing what you come up with, for this, or other projects. So, let's move on :) --FeralKitty (talk) 02:25, 3 May 2009 (UTC)
I want to tell you some of the ways you spelled the items, i.e. WaterLily is different from waterlily and waterLily. All your links wont work with that PVC that I have downloaded because the waterlily links all have to say WaterLily-TroubleInParadise-PV.jpg I am sure you know this and will be changing it so all links will work. (or possibly uploading ones with that name?) If you need help with the links I could also help edit your page or download some PVCs of whatever you have not yet. I think it's preferred that you use the cards already listed, though :P Let me know :)--ImaTestWentBad 04:13, 4 May 2009 (UTC)Sorry, I forgot to mention something else. I am just saying it in case you didn't knowThere seems to be a theme going with naming of the cards. Some of the PVCs that are developer cards have a file name of PinatanamePV.jpg while the ones that are not special, (vp.com cards) have a file name of Pinataname-TroubleInParadise-Variant#-PV.jpg --ImaTestWentBad
Lymaniii and I corresponded briefly in private about this article; I'm bringing the discussion back to the wiki so we can debate site navigation and conventions.
First of all, navigation is how to get from point A to point B. Adding more information to a page so people don't have to travel to another page is not navigation, and it's not accurate to call it an improvement to navigation. Adding information to a page because it's the topic of the page is normal. Adding another page's details to a page merely to spare the user from having to travel to other pages isn't a solution, and leads to bloated pages with off-topic details. If page A isn't about topic B, topic B's information probably shouldn't be also repeated on page A. Instead, links are provided to get to topic B. Isn't that a reasonable convention?
Second, (site) navigation is something that's meant to exist and function consistently (across the site as a whole). In other words, pages should have the same navigation look and feel to them. A site isn't meant to have differing navigation (this approach on one page, another format on a different page, no navigation on a third page, a mix of styles on a fourth page).
I think this is a great user page (article), and if you feel it helps "site navigation," then it certainly can function well from within your user space. But if you want it to be something that eventually becomes a part of the main wiki, is there a reason why this page should do several things differently from how other pages work?
  • Linking to a raw image brings the user to a page without navigation at all. It's as if they've left the wiki.
  • Linking Arocknid to an image behaves differently than every other Arocknid link on the site. It's expected that an Arocknid link takes people to the Arocknid article, not to a picture of an Arocknid. Links shouldn't behave differently, on different pages; adding a "disclaimer" that these links take people to images instead of articles isn't a "solution." (That's a workaround to a problem that shouldn't exist, because of reasonable conventions.)
  • If links are to PV images, and your Arocknid link takes people to an Arocknid image, and your Blueberry link takes people to a blueberry image, what does a PV link take them to? A PV image? I don't mean to be facetious, but you've used two specific link terms, then switched to a vague term, mid-row. If it's a pinata vision card of a species variant, I'm not sure if PV is a good term for that, especially since PV doesn't mean "species variant."
  • You provide links to images, instead of thumbnail images. All the other main space pages use images, not links to them. Why make this page behave differently for the visitor?
As an example or an aid to you or others, it's a fine user article, but if there are better ways or standards you're proposing for the site in general, but don't have the time to overhaul other pages, that's a good reason why this should probably stay in user space until there's time or attention to changing things in general. Consistency is important for look and feel, for behavior, across the site, and many sites across the internet adopt and embrace that design principle. If you have complaints about the design, I don't follow the logic that a mix of long-term inconsistent approaches between main-space articles is an improvement. --FeralKitty (talk) 23:32, 4 May 2009 (UTC)
Because someone once said "criticisms without solutions aren't helpful," I'll offer a suggestion which might help make this table more compatible with existing links:
Species Variant food
and varianted pinatas
Wildcards Trick food House
Barkbark
Barkbark
Banana split
Barkbark variant 1
Poison ivy
Barkbark variant 2
Medicine
Barkbark variant 3
Barkbark wildcard 1 Barkbark wildcard 2 Barkbark wildcard 3 Wool
Milk
Barkbark house
This way, text links go to expected articles and the "PV" link becomes intuitive. The obvious problem, however, is that the page would load over 700 thumbnails. I realize that you want the cheat sheet to perform double-duty as a one-stop link farm direct to named pinata vision cards, and that I omitted showing a few food images. (If the complaint is "navigation," i.e., not being able to find the cards, wouldn't the text link get them to a page that should contain the card? I'd think it would be more helpful for some visitors to get to a detailed article with lots of information, instead of merely an image.)
If text is preferred, then I still think links to articles keep the page consistent, and you could try something like:
Species Variant food
and varianted pinatas
Wildcards Trick food House
Barkbark File:PV icon.gif Banana split File:PV icon.gif
Variant 1 File:PV icon.gif
Poison ivy File:PV icon.gif
Variant 2 File:PV icon.gif
Medicine File:PV icon.gif
Variant 3 File:PV icon.gif
File:PV icon.gif File:PV icon.gif File:PV icon.gif Wool File:PV icon.gif
Milk File:PV icon.gif
File:PV icon.gif
I think a visual cue may be more helpful to show what the PV text would link to. The only issue is that this example currently won't work at our site, as it relies on features found in 1.14 (or the ImageMap extension). Still, I think it's helpful to continue to distinguish between text links which have gone to articles, and some new form of link that you want to use, to get visitors to a PV card (article). --FeralKitty (talk) 10:28, 5 May 2009 (UTC)
Linking to a raw image leaves the user without navigation as if they've left the wiki, but this may be better than linking to the image's wiki page for a few reasons: 1) the wiki page loads more slowly and most of the information on there is irrelevant to someone who is merely browsing images (the nearly universal purpose I would anticipate for which someone would be linking from this PV index page) and 2) when the image loads alone, one may be able to scan it immediately off the screen without scrolling down. This is the case on my computer and it's a small but real irritation to constantly be scrolling every single image I want to look at because it is presented within the context of a full wiki page. 3) The only navigation I typically use on image wiki pages is the back button, and that will always still be available. So, yes, this is unusual and certainly not preferrable in a typical link situation, but still may be an appropriate design option here.
The convention that a word must link to the article by that name is also a wonderful convention in general, but pretty hobbling when you're creating an index in which it is explicitly stated and understood that all links lead directly to images only. The existing species list and species page structures offers suitable navigation for the purpose of browsing to a species page and then selecting further browsing options including PV cards, but this page is deliberately intended to be concise and direct for the very purpose of organizing images themselves. This same thing could be done if the links were not species names but names of images, but it's easy to see that the table would quickly become useless if each word on it were replaced with the sentence-like image naming convention the wiki employs. There's no way a table of 8 or 9 columns could be contained within a reasonable non-horizontal-scrolling page size as it is now. Whether you consider it a work around or not, the "reasonable" thing when considering a new page to fulfill a new need is not to force it to replicate the function and design of existing pages and then fault it for being redundant. It would be wonderful to avoid a disclaimer or special instruction for the page, but it is the unique nature of the page that means that there may be a choice between strict adherence to convention and no page, or finding ways to communicate the unique nature of the page and having a very useful additional feature to the site. I prefer the latter, but if there's a way to mitigate the ambiguity without all the awkward explanations, I'm in favor of that as well.
I used the vague term "PV" in the table recognizing that it's not clear from the outset what it means The reason for using it is that it is brief and allows for the brevity of the table that I consider to be the crucial design aspect of the table that justifies its separate existence. The table you've created above with the thumbnails of the images is exactly the idea that I initially had in terms of this idea, and I still think it would be a better approach. However, loading a page with about 700 images is probably not going to work well for various reasons, and as you indicated. The options I considered then were to 1) link from words rather than thumbnails allowing for a complete one page summary index of representative PV images (much of which can fit within a single screen), or 2) break the index into about 10 pages of 10 species each (similar to the way vivapinata.com breaks down the species) and have an index of the index. Either of these options would please me, frankly, but the first option was a lot easier to execute and tinker with. Because a visual index is vastly superior in my view, if the site could handle the bandwidth I would opt for the latter though. On the other hand, the secondary purpose of the page is a quick reference to foods that will variant or teach tricks for *all* species rather than requiring one to flip from species page to the appropriate tab, to the next species page, etc. Page loading time is a real issue for many people (me included), and having a table that has a nearly comprehensive set of PV links as well as key award requirements, and that loads in less time than a single PV image seems like a winner. [Incidentally, I consider "navigation" to be the whole process of a user finding the information they are looking for, whether it's on a single page or many pages. Balancing the drawbacks of unwieldy large pages with the drawbacks of many clicks is a tricky thing, but it's a start to recognize that *both* extremes are navigationally inadequate.]
I am in no way suggesting an overhaul of site standards or conventions or other site pages. What I am suggesting is that there are valuable ways of presenting information that may be impossible to execute without a little leniency in said standards, and that after some consideration it may be possible to execute without a bad impact elsewhere or in other parts of user experience. I imagine this index would be in addition to the existing pages and would just be linked from the PV image category page and perhaps other relevant referring pages if it were to become a highly used part of the site. Consistency is a design principle I whole-heartedly embrace, but rules are meant to be broken when there's a good reason, and a careful execution of a thoughtful and deliberate exception is not quite the same as "a mix of long-term inconsistent approaches".
Your second table example is also perfectly in line with what I'm trying to accomplish and I would be delighted to use that approach. It has the added benefit of working with existing naming conventions (which I didn't think would be possible, but allowing for an extra line of text does wonders, I guess, albeit with a sacrifice in page brevity), but the disadvantage of not being possible. Bummer.
I appreciate the suggestions, and I'm happy to see that there may be ways of approaching this that would be acceptable. [Sorry I forgot to include a timestamp on this before! Lymaniii 22:20, 5 May 2009 (UTC)]
Raw image links are unfriendly for a few other reasons, outside of suddenly dropping a person onto a page with no navigation. First, some of the PV cards are at native resolution from VP.com. This means if the viewer's resolution can't support an image that's 1024 pixels wide, they'll have no way to easily view a lower resolution. The wiki page manages that for them, instead of forcing them to save an image and rescale it themselves. Second, landing pages should be wiki'd because visitors do come here from outside the site (e.g., links to us from other sites or from search engines). Also, I have a feeling that Jim would say the "irrelevant" content (e.g., ads) is something he'd want people to consistently see. --FeralKitty (talk) 21:54, 5 May 2009 (UTC)
I don't know Jim at all, so I don't know what kind of premium he puts on ubiquitous advertising, but in the sites I've managed, more ad spots on a page does not always translate to additional user clicks, and it's therefore unproductive to insist that they are there as a constant first priority. There are plenty of other options for people to see ads on the site.
As for the image issue, you are probably aware that most current browsers resize images to fit within the viewable window, and this only works automatically if the image is opened *as* an image, not as a part of a page requiring scrolling.Lymaniii 22:20, 5 May 2009 (UTC)
I don't think I insisted that ads should be there or that they are a first priority. Let's not put words in my mouth :) I'm not going to debate ads since the question simply should be whether links should go to raw images or not. Yes, I'm also aware that modern browsers can resize images, if enabled, but we shouldn't exclude some percentage of visitors whose images wouldn't be resized. Perhaps Jim can decide about raw image links, since we're going around in a circle again. --FeralKitty (talk) 22:58, 5 May 2009 (UTC)
IMO, different link behaviors isn't something the visitors should have to deal with, but feel free to take up the "links sometimes go to different places" topic with Jim. I'll go along with what he decides.
Exceptions based on "we'll do things differently on this page because we have good reasons" aren't forms of comprehensive and inclusive solutions. While there's nothing wrong with doing things new ways, or coming up with ways to handle new things, consistency implies that these (old or new) approaches are whole-heartedly uniform across the site. Proposing to handle something a new or different or better way should be site-centric, not page-centric. Frankly, it's hard to clean up a mix of different styles, after the fact, so it helps editors out from having to reword or restyle or relink things things similarly to fit in with the style guide or conventions. --FeralKitty (talk) 21:54, 5 May 2009 (UTC)
This, of course, is and has been the crux of where we disagree. Utility and purpose trumps rigidity and dogma. The purpose of having a site-centric consistency is because it generally facilitates that utility. When it ceases to do so, you just have to let go. Whether this is an instance of where this is the case is debatable, but the principle itself is something of which I'm quite certain.Lymaniii 22:20, 5 May 2009 (UTC)
We disagree because I argue that utility and purpose should work in conjunction with consistency, not independently of it. Let's just agree to disagree, because I think there's not much new to say, and we're really not getting anywhere at this point. --FeralKitty (talk) 22:58, 5 May 2009 (UTC)
As for "not being possible," ask Jim if he'd install the ImageMap extension for you. It's the simpler effort for him, although a bit more complicated for you to mark-up inline. --FeralKitty (talk) 21:54, 5 May 2009 (UTC)