Pandora PND packagers: 1) Please provide previewpics. 2) Define primary pic if you give multiple!

[porg]

Dear PND developers / packagers / maintainers!


For an improved usability it would be fine if all PNDs:

• come with a preview picture (<previewpic>)
  
• and define a primary preview picture, as many contexts only show one picture (MiniMenu, Repo RSS, etc)
  

I added a more detailed recommendation at: http://pandorawiki.o...pics.3E_element


and created a suitable short URL: http://pnd.to/previewpic


and already informed some maintainers through comments in the repository or through personal messages.


Follow up:

• If you are a maintainer yourself, please follow that recommendation if possible.
  
• If you are a core developer, maybe consider an (explicit) technical definition for a primary <previewpic> within PXML
  
• If you are neither of these, but still get in touch with the topic, then you can at least use that URLs above to point people to the related recommendations for providing PNDs.
  

Regards, porg

 

[iprice]

I notice you've put comments into the feedback form for Dino Defense on the Repo.

@iprice: Please set the MOST ILLUSTRATIVE PIC (in-game rather than main menu screenshot!) as PRIMARY in the PND PXML definition, as many contexts consider only the first pic: MiniMenu preview, Repo RSS feed, PNDManager app info (more pics on demand), etc. http://pnd.to/previewpic

Sorry, but what gives you the right to demand that, especially in the feedback section of the repo? The first image (of 3 given) as displayed in the Repo clearly illustrates the gameplay (as best as a single non-animated screenshot can) without giving away too many spoilers. I have also given the game a clear description, explaining the game concept.


And you're still not happy?

 

[sebt3]

Relax iprice, porg like to agressivly report what he think like an horrible issue

 

[porg]

I thought that starting my comment with "please" was a clear enough lingual marker, that this is a mere "wish" (in order to improve the Pandora platform usability) and not at all a demand. Sorry if my message arrived to you as an insult! Was definitely not the intention!


P.S.: I (and other users as well) use the repo as a medium for reviews, but also bug report and feature suggestions. So far, all maintainers appreciated my non-review-type comments, no-one yet told me "This is for reviews only". Therefore I thought my communication style on the repo was ok. If I should change it, please tell me.

 

[fusion_power]

Be careful, we've recently got Streak back at the repo, but you could easily make him run away again if you are to rude. ^^"


I really like preview pics of an app, especialy when I don't know anything about the app. But I wouldn't force anyone to make preview pix, especialy not in a certain pattern. However, some more detailled descriptions in the repo could be very helpful. Some of the info text there is really short.

 

[Christoph.Krn]

This is not about porg or his wishes, it's about every single user of any PND repository and PND package manager with previewpics-support. So, if this topic is not relevant to you, it's best to just ignore it.


------------------------------------------------------------------------


In a way, providing these instructions means to make the same mistake that the instructions are trying to help others prevent. It's not like there wouldn't be enough information about these sort of things available on the Internet already, so the issue is not about directly providing instructional information. Rather, it's an issue of attention, and just like many <pic>-element-instances out there today, the /design/ of the current instructions is constructed based on a misconceived intended purpose (or at least that's the way I see it).


As a representative-ish example take an explanation like "It [an illustrative picture, remark] should quickly give an impression of the look & feel of an application." (PXML specification <previewpics>-recommendations on pandorawiki as of 2012-04-29T16:18). The way I see it, such a sentence can only be truly understood by those who already know what it means, ergo it is only truly understandable by those who do not need it. This means it does not fulfill its purpose because it does not teach those who do /not/ understand it why they might want to be paying attention to it. This in turn explains why there will be comparatively many people who negatively comment on it, because they believe it's something that /you/ want (well, I'm aware that you actually do, after all you're also a subset of the Pandora's userbase).


A specific suggestion that I have for improving the situation is to create an overview of good screenshots versus bad screenshots, with information on where to find more information (such as links to external websites; or to a separate, more elaborate explanation on the wiki).


A relevant recommendation I have for each and every developer reading this by the way is to watch a video on YouTube called http://www.youtube.com/watch?v=Th_1azZA2OY.


I hope this was helpful.

 

[iprice]

I'm fine with it being a suggestion (and do tend to agree that more info and images is a good thing) on the forums, but putting it into the feedback for items uploaded to the Repo using UPPER CASE requests appears more than a mere wish. My information available on the repo for DD WAS more than average and included everything required as part of your "wish". It was totally unnecessary.

 

[vadsamoht]

Perhaps a simple solution

I'm fine with it being a suggestion (and do tend to agree that more info and images is a good thing) on the forums, but putting it into the feedback for items uploaded to the Repo using UPPER CASE requests appears more than a mere wish. My information available on the repo for DD WAS more than average and included everything required as part of your "wish". It was totally unnecessary.

Perhaps a simple solution to the problem may be for a native English speaker to re-word porg's comments. While I certainly don't want to insult porg's English skills (especially when my Japanese is barely comprehensible), it seems to me that the capitalised words are there to provide extra emphasis that may help clarify his intention (out of concern that the sentence may be ambiguous as is often the case with anybody speaking their non-native language) rather than to seem aggressive.

 

[porg]

@iprice: In retrospection, I realized that the upper case writing, even though only applied to 4 words, can be considered rude. Sorry. The further maintainers I contacted through repo comments got their writing in normal case, and I added a conjunctive (Could you …) to be even more clearly polite.


@Christoph.Krn: I agree with your communication theory analysis, and would be delighted, if you could revise the recommendation concerning previewpics at the wiki accordingly.

 

[porg]

@vadsamoht: You got me! The 500 character limit on repo comments is linguistically challenging. It was hard for me to deliver my message within that constraint, plus giving an example, plus an URL, and thus I used the uppercase as a marker for emphasis as the comment text is plain text only.

 

[iprice]

But that still doesn't negate the fact that my app did/does show images of in-game action, and in the order of importance, with the title screen being last. Posting the message was unnecessary.


Having it in the forums or on the wiki, and even when peeps are uploading stuff is absolutely fine. More than fine and as i said, agree with the recommendation. And it is just that, a recommendation.

 

[porg]

Should my <previewpic> comments to maintainers within the repo be widely considered as to be in the wrong medium, they should be easily remove-able in a batch process:


Comment from "porg" containing the URL "http://pnd.to/previewpic" posted on 2012-04-29.


Should you decide to do so, please be so forgiving this one time, and leave my comments for another 2-3 weeks, and only then do the cleansing.

 

[vadsamoht]

I don't think iprice is saying your comments should not have been made on the repo, it's that he thinks the information he had already uploaded was good enough already.

 

[porg]

But that still doesn't negate the fact that my app did/does show images of in-game action, and in the order of importance, with the title screen being last. Posting the message was unnecessary.

Sorry, but this is not correct. MiniMenu shows only the primary preview picture dino1.PNG (title screen) whereas the supplied but unshown dino2.PNG depicts in-game action and dino3.PNG the paused screen.


I would even say, that because your title screen shows the typical landscape from the in-game scenes, it is enough for recognition, but it misses the sprites, which are the elements which make the game visuals complete and characteristic.


Else, I would not have sent you the message.

 

[iprice]

I don't give a toss about Mini-Menu or RSS feeds or any other form of publishing data about MY game etc. I was talking specifically about the standard Pandora Repo, which clearly shows three images and my text. If you can't see the images in some other form, then that is NOT my issue or fault. And that is not what I am talking about.

 

[mcobit]

Well, it is a matter of renaming two files or changing the order in the PXML, if everybody feels better then, I can change the pnd.

 

[iprice]

No - that is not the issue mcobit (although maybe the root of the problem). A comment was made ON the repo about a problem that may be evident in software that is NOT the Repo (the only place that I can actually see my game).

 

[mcobit]

Minimenu is on the nand and the default minimalistic app launcher. I think it should be supported. Thats all.


Porg has a point, but if someone already installed the app, he should have seen the previewpics before, so it is not a big deal really.

 

[porg]

I don't give a toss about Mini-Menu or RSS feeds or any other form of publishing data about MY game etc.

Let's try this in a cool rational style:


The purpose of supplying previewpics is that your potential users see them for discovering your app (first use) and recognizing it while browsing (later use).


Agreed?


If we agree on this, let's continue that thought:


There are multiple software environments which make use of that previewpics: The repo website, launchers (such as the official (!) MiniMenu), package managers (as PNDManager), etc.


Many of those softwares tend to only show 1 picture, and the remaining not at all, or only on demand.


Sadly there is no definition, which picture is to be primarily shown, which could lead to the case where the most important picture, into which the maintainer probably invested the most efforts, is not shown! Would that not be a pity?


And this circumstance is what I stumbled upon, and wanted to constructively improve, by informing:

1. Package providers about the de-facto standard (in most cases: the first <previewpic> in the source code which gets parsed and/or the first in lexicographical order)
   
2. The core team aware that it might be good to extend the <previewpic> standard definition, so that a primary picture is not a technical coincidence of respective implementation logics.
   

I wanted to help out constructively (I am an interaction designer by profession), and spent my Sunday afternoon for this community work (writing the wiki page, checking various PNDs, informing maintainers, discussing here). Do you see now, that I am not an impolite person, but someone who wants to contribute?


Ok, I hope this is clear now, and that those involved will carry on.

 

[foxblock]

Well this might be a "problem" of the repo, too, as it displays the previewpics in reverse order (as specified in the PXML) from left to right.


Programs will probably display the firstly mentioned pic.


So I guess this could be changed in the repo.