At the urging of @ArchFeral I'm considering redesigning the UI of my Playlist Generator. One of his ideas is that the main display of cards should look like the My Collection Tab of iStripper. That makes sense and it turns out that it is not so hard to accomplish in Microsoft Access if you are willing to be tricky. Attached is a prototype display sorted by model name that I put together in about 3 hours.

This raises some questions. iStripper offers two display formats. One is card images only and the other has smaller images plus some text. I like the larger images. What do you prefer? The prototype displays the card image at full size with some information.

Doing all the sorts supported by iStripper is easy. Since I'm working from a database, combination sorts are also possible. For example I can sort first by collection and then by model name within a collection. However, I have no idea what might be useful. So: What kinds of sorts would you like for your collection? Also, what facts would you like to see along with the card image? What information is most important to you?

I like what I see, @Dorsai6.

I also prefer viewing my collection with regular card images (as in your prototype display) instead of smaller images that are used in store.

In GUI I normally sort my collection by name (model), card number or purchase date. I think any combination of those would be useful.

It's too bad that one can't read card release date or card hotness level (as presented in GUI) from card XML-files or models.lst, as far as I know. I would love to be able to sort first by model and then by release date, but that is not currently possible. "Purchase date" would be perhaps nice info to have visible under each card, if there is enough room, but not all that necessary. Resolution and estimated card length are good to have there.

Regarding "Hotness level" and "Release date"... would it be possible for you to add fields for these in the "iStripper Card"-table and then option to use these for sorting, and also to include these fields as information under each card? Obviously these fields would be initially empty because they can't be extracted from the files, but users might want to add that information manually themselves later on. Maybe a form where user can fill in this information card by card? "Hotness level"-field could a handled with editable predefined list (initially Nudity / Full nudity / XXX, but with space reserved for possible other levels to be added in the future, or for user's own classification?) and Release Date -field with same formatting as purchase date.

I also prefer viewing my collection with regular card images (as in your prototype display) instead of smaller images that are used in store.

I would like to be able to toggle between the regular card images, the non-nude full body images and the nude images - this applies equally to both for @Dorsai6's database and for the iStripper GUI.

@Dfner,

Thanks! At present, I can't get at the release date. However, there is a second date field in the models.lst file that I have never understood. Let me look into that. Hotness level can be derived from clip data, so I can do that. Moreover, I can count the number of clips by hotness level and display that. Anything I can display I can also sort and filter on.

Since I already have provisions for user created tags at both the card and clip levels, you can already tag them based on your own criteria. Now we are getting into a difficult area. Anything that is tagged can be counted and totals can be displayed, but adding a general capability for this would be a lot of programming and might cause a significant performance hit.

@TheEmu,

The Playlist Generator already stores the full-body image, but displaying it in a tabular format probably would't work very well because of both the image's size and aspect ratio. The nude images aren't currently in the database. Adding them would probably double the size of the database and that's a serious issue for anyone with more than 1000 cards. Also, not all cards have a nude image.

@Dorsai6

If the size of the database is a serious consideration would it not be better just to store a link to the image rather than the image itself in the database?

Hotness level can be derived from clip data, so I can do that.

That's true, but I'm sure @Dfner is talking about the overall hotness level of the entire show.
Actually, this information is available in the xml file. Open any xml file and look for this element:

<root>
....<show>
........<level>X</level>
....</show>
</root>

where X represents the hotness level:

2 = Topless (only one card: a0005)
3 = Nudity
4 = Full nudity
5 = XXX

@lukaszr Yes, that was what I meant and it's interesting to know that it's available in the XML-file. Thanks for the info, I didn't know that.

But perhaps it is still essentially the same thing as Dorsai6's idea of deriving it from clips. I haven't checked it, but I believe the hotness level is always defined by what is the "hottest" level clip in a card. If there are cards that are e.g. categorized as "Full Nudity" in GUI but still have even one XXX-clip in them, that would be quite surprising at least to me.

@TheEmu

If the size of the database is a serious consideration would it not be better just to store a link to the image rather than the image itself in the database?

I never thought of doing that. For a variety of reasons I'm in the habit of building stand-alone self-contained databases. The Playlist Generator is the first time I ever included photos in a database. 90% of the Playlist Generator's size is for the images and Access starts misbehaving when its tables get too large. I'll look into this. Because I run iStripper on my Mac and the Playlist Generator runs on a virtual Windows & PC on the Mac there may be some specialized problems, but it's worth checking out. THANKS!

@lukaszr

Actually, this information is available in the xml file.

I make extensive use of the xml file but I never cared about the card's hotness level and I never looked to see if it was there. Thanks, I'll modify the Playlist Generator to include that in the future.

@Dorsai6

one thing you could add.
read the Data folder location from the Registry..

Then you'll also have the path to all of the images.

the Paths are in a FIXED location
HKEY_CURRENT_USER\Software\Totem\vghd\System

the key is
Datapath

read the value of the key

@Dorsai6
To answer the question you posed in your opening post:
I would prefer card images only.

@Dorsai6 Looks great :D, and nice to see discussion happening. I don't have too much to add at the moment, but if I think of something I'll make sure to drop a comment :)

@Dfner

I also prefer viewing my collection with regular card images (as in your prototype display) instead of smaller images that are used in store

I'm a bit *****.

In the store there are two display modes. Once shows card images and the other shows the full image plus a lot of text but cropped at the knees.

In My collection there are also two display modes. One shows card images and the other shows just a head shot and a little text.

In both the store and My collection, the card images size can be adjusted from about 40% to 100% of full size. So, what did you mean by smaller images that are used in the store?

@Dorsai6

It was about this part of your post:

This raises some questions. iStripper offers two display formats. One is card images only and the other has smaller images plus some text. I like the larger images. What do you prefer?

I thought the "smaller images plus some text" meant the images+text as we have in the store (see screen cap above). And that if there was a choice between them and the regular card images, I'd prefer the latter.

OK! I can easily display a table of card images sorted in any order you wish. I created a sort wizard that will let you create any sort you wish of whatever complexity you desire as long as the data comes from the card, so I don't need to ask what you need for sorting cards. Attached is an image of the control. It only shows 4 rows, but it has now upper limit. At present it works with the following fields:

Model Name
Collection
Card Number
Card Title
Rating
Resolution
Hair Color
Date Purch
Folder Size
Play Time
Times Played
Selected
Just Imported
XXX Clip Count
Full Nudity Clip Count
Nudity Clip Count
Topless Clip Count
No Nudity Clip Count
Number of Clips Selected

The filtering capabilities are even more powerful and I have some ideas about making it simpler.

Now my dilemma is how useful is this? On a standard size screen (1920 X 1080) you can only see 16 cards completely and the top half of 8 more. One a larger screen you could see about 40 cards at a time. This is showing the card images at full size. With the card images scaled down to 50% you could see 4 times as many cards at once. Is this useful? What would you do with this capability? If you are making a playlist this can help you confirm that the right cards will be included. Is there something else you might use this for?

@TheEmu or anyone who has done this

If the size of the database is a serious consideration would it not be better just to store a link to the image rather than the image itself in the database?

Well, I have tried. I can link a static image field in access directly to a .jpg file using the path name. It's a bit slow, perhaps .5 sec. on my computer, but it works and it would save a lot of space on the database.

However, I can make this work for a continuous form in Access which I need to make the tabular view of card images work as shown in my original post to this thread. If anyone has experience in Access with multiple lines of images drawn from outside files, let me know. I'll be happy to show the code I'm using.

EDIT:

Last paragraph should begin: However, I can not make

I've been working on an improved sort/filter capability for my Playlist Generator. Attached is an interesting example.

This searches all cards for those where the total of Fully Nude + XXX clips are between 10 and 12. Then it sorts in descending order first on that total, next on the number of XXX clips and finally on model name. The filter and sort are completely independent. I could have sorted just on model name or on XXX clip count plus model name.

The display allows one line of data. In this case it displays the number of clips by hotness level 1-5 reading left to right. There are about a dozen alternative data elements that can be displayed, but many of them are worthless. Since this was easy to do I threw in everything about a card.

These selected cards can be written to a play list with a click of a button.

Comments?

Looks very nice! Visually very clean and easy to take in. I very much like this way of seeing the overview of cards contents by hotness level, AND the fact that you are including that drop down menu where user can select alternative information to be shown.

Just out of curiosity, what are you plans with that "Card Filter Group"-sheet?

Also, I like the "Card click"-menu on the right, that's definitely a new functionality. I assume the first menu item is "Show details", but what other actions have you planned there?

Right now the card click has just two choices:

1. Go to the cards and clips tab to see all details about the card. The cards and clips tab is now sorted and filtered automatically to match the cards display tab.

2. Toggle the selected status of the card. This lets you "tune" the filter results.

At first I tried to make one of the above a double click, but double click doesn't work for an image control in Access. Since I now have this as a potentially multi-choice item, I'm interested in suggestions for other functions.

The "Card Filter Group" is used to create and run a filter. It creates the descriptive data shown as filter rule. Right now it is a tab on the main form, but I'm debating making it a dialog window.

I'm trying to keep the controls small to allow the most space for the card display itself. I'm also considering an alternate mode that will reduce the card image to 70% to allow more cards to be seen at once.

Whether or not you are using my app, I welcome your comments. Who knows, Totem may decide to implement some of these features.

I'm continuing to work on the improved UI for my Playlist Generator. I'm going to continue using this thread to discuss UI issues related to sorting and filtering cards.

From the looks of things, I'm going to have three tabs that will be used to display filter results and refine selections.

1. Model Display will show one card per model. The card used will be first in sort order as set by the user.

2. Cards Display will show every card in the sort order set by the user.

3. Model Details will show one page per model with all cards of that model shown in sort order.

At present all three tabs will support two different click-on-card functions. One mode will toggle the selected status of the model clicked for tab 1or the selected status of the card clicked for tabs 2 & 3. The other mode will open a detailed page for the card or model clicked. Now, here's is my question:

The click setting is modal behavior. I can have one control that applies to all three tabs so that clicks behave the same way on all tabs, or I can have three separate controls one for each tab so that clicks behave differently as you wish on each tab, or I can have two controls one for clicks on a model on tab 1 and the other for click on a card on tabs 2 & 3. What makes more sense? It's just as easy for me to do it either way. I suspect that whatever I do some people will see it as a clash with their expectations.

Regarding your question: would it be possible to do the click-on-card the way it is handled on Models-tab, in the current version of your tool? So that if you click on card, you get to the details page, and if you want to select the card, you "stamp" that "Selected"-tag under each card (see pic above)? I think that would be best option at least for my use. And similarly on tab 1, if you click on model (first card of her shown), you get to the model details page (tab 3), but there would be these "Selected"-tags too, for model selections.

And if that's not on the table, is it possible to use actions of left click / right click / double click separately in Access? So that e.g. double clicking would open details page and single click would select card / model etc.?

@Dfner

would it be possible to do the click-on-card the way it is handled on Models-tab

Yes, it is possible, but there are some problems. The approach I used on the models tab worked fine when the number of cards was small (< 100). When I tried to scale it up to support > 2000 cards in the new Cards tab I ran into performance problems that I could not easily solve. Instead of trying to solve the performance problem I took a different approach that uses a non-updatable query which can not support a clickable check box.

Access supports both single-clicks and double-clicks on a control, but I've never used both for the same control. When I first tried this a few days ago, the double-click was not recognized. Today I did some more experimenting. It seems that there is a timing issue. A double-click always triggers a single-click first for obvious reasons. In my first tests I was using single-click to jump to the details page. It worked so fast that there was no double click. I've changed the logic so a single click toggles the selected status. This allows the double-click to be seen and recognized. All I had to do is add an undo for the single click that was really part of a double click.

Thanks for poking me on this issue. I've now eliminated an unnecessary control, unless someone comes up with a third reason for clicking on a card image.