• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Feature Requests for Presence Builder 11.1

JonathanRockett

New Pleskian
Hi Team,

As we are approaching the end of Q1 2013 (previously mentioned by Parallels as a target for release of 11.1), I thought I would start a thread for last minute feature requests :)

These may already be additions to the new version, and may have been mentioned already elsewhere in the forums, but just in case...

1. Expandable entry fileds for Custom Script module and Edit Metadata module - I realize most users are not adding a great deal of code to the <head> or to the Custom Script module, but for those of us who are, it's a LOT of scrolling to see all of the code in the box. The ability to expand those boxes to full screen would be great, or even to simply drag a corner and expand the viewable area. Ironically, the Edit Metadata box can be expanded by dragging a corner, but the actual content field remains the same size - only 4 lines of code visible at a time. Very frustrating. See attached images.

custom_script.png edit_metadata.png

2. Better display of documents in Document Manager - The icons used are very large, allowing only a handful to be seen at once without scrolling. Also, the documents seem to simply display in the order they were uploaded, rather than by a more typical directory structure (alphabetical, file type, file size, etc.). There is no way to reorder them or see them in 'list' format, so if you have more than a few documents present it is very difficult to find the one you need.

document_manager.png
 
Hi Jonathan,

I've filed your first request in our system -- frankly, I have no idea why we didn't think of this before...

The second one is more tricky. We've already investigated this, and it looks like even if it seems that making a plain list or smaller icons should display more items on the screen, in fact there's no significant advantage over current design. We'll continue to think about this, though.

Thanks for your requests -- please keep them coming!
 
I support both requests of Jonathan.

Document Manager:
The current display in WPB resembles the thumbnail view in operating systems such as Windows or Mac OS. Those thumbnail views allow to find files more easily and quickly by providing a preview of the content. On the other hand, the list views provide more details such as the full file name, file size, date and are sortable. So, the content preview feature is the key asset of the thumbnail view and the reason why it is used.

With the current Document Manager display in WPB I see these disadvantages compared to the views of Windows/Mac OS:
- File types are shown as symbols but without preview of the content.
- File names are truncated - only the first 15 letters or so are shown.
- File details appear after clicking the file icon only.
- Display limited to 8 files without scrolling.
- No sorting possible.

It would be nice if the usability of WPBs Document Manager could be improved as follows:

1. List view as the default view.
2. List view shows small file icon, file name, file size, file date.
3. List is sortable by those attributes. Default sorting is on file name, ascending.
And maybe 4.: Switch to thumbnail view with a content preview.

Point 4: A thumbnail view is more useful for image files than for document files. Since WPBs Document Manager is mainly used for documents, a list view would be sufficient.

I hope these thoughts help for your reconsiderations.
 
Last edited:
The second one is more tricky. We've already investigated this, and it looks like even if it seems that making a plain list or smaller icons should display more items on the screen, in fact there's no significant advantage over current design. We'll continue to think about this, though.

If you think that making the icons smaller or providing a List view provides "no significant advantage" then you've clearly not used the document manager very much. Lol. My tiny smartphone screen displays files better.
 
OK custer, you said "Keep them coming" so here's another one:

Revision Control (Save and Revert tabs) - I feel this is very confusing, especially for the type of website owners that a dummy-proof, drag and drop product like WPB is ultimately designed for.

(Heck, it even confuses me and I've probably used WPB more than anyone. Here's the latest: http://magneticmonkeycreative.com/)

Per the first two screenshots attached, the Save and Revert drop-downs are basically identical - They both offer the same icons beside each snapshot slot to download that snapshot to your computer, upload a snapshot into that slot, or remove it. The only difference is the Save drop-down has a 'save' button at the bottom and the Revert drop-down has a 'load' button at the bottom (which, btw, should read 'revert' for consistency - too confusing). The redundancy created by duplicate functions in both menus is extremely confusing. Wouldn't it be SO much simpler to just combine them into one drop-down menu called 'Saved Versions' (or similar) with have a 'save' AND 'load' (or revert) button at the bottom per the third image below?


Save.png Revert.png Save_Load_combined.png
 
I would certainly agree about the save and revert tabs being confusing for many customers as per Jonathan's comments above. Also having the saves automatically rotate through the empty save slots would be an advantage. I've seen many customers who only click save which keeps over writing the same save file, so when something goes wrong they don't have any other versions to revert to. Ultimately its the customers fault for not using all save slots but if you improve the save function to auto rotate through empty slots and maybe prompt to over write oldest it would help a lot.
 
Guys, I support your suggestions (combination of save and revert in one box, rotating slots with direct save).
 
Also, while we are touching on the subject of version control, I've noticed something else that is very confusing and could be fixed on the simplest level without any programming, just clearer language on the warning messages:

Under the 'More' tab on the menu are the items: 'Start Over' and 'Remove Site' - They both take you back to the Categories start page, and it's not clear what the difference between the two is. I imagine most users will think (as I did at first) that the 'Start Over' button will erase all your design work in the Wizard and take you back to the beginning to 'start over' on a new site.... and the 'Remove Site' button will erase your design work, take you back to start and actually UN-PUBLISH your site from the web (i.e. delete the site files from the hosting account completely) or at least render the site inaccessible to browsers.

Neither of those two scenarios are true.

The Start Over button gives the warning:

"Confirm Starting Over
If you choose to start over, your current website visual design and content will be deleted.
Are you sure you want to start over?"


But this is incorrect. Any saved snapshots (including auto-saves) remain in the Wizard upon starting over, but users aren't made aware of that, rather left to assume ALL their work will be deleted.

The Remove Site button gives the warning:

"Confirm Removing Website
If you choose to remove this website, you will not be able to restore your current website visual design and content later.
Are you sure your want to remove this website?"


This is actually true, but it should be clarified that the site will not actually be 'removed from the Internet', simply from the Wizard. There is currently no way for a user to take their site down from the web (without ftp access and technical knowledge, which users of this product generally don't have, and my clients don't have access to their Plesk Panel). The ability for an end-user to 'take their site down completely' should be taken into consideration...


SO HERE'S MY SUGGESTION:

Rather than having two, almost identical removal features, why not simply keep the Start Over button as it is (retain any existing snapshots since they can be deleted there manually anyway) and clarify in the waring message that saved snapshots will be retained. And have an Un-Publish Site Completely feature for removing a site completely (with an appropriate warning explaining such).

If you don't like that idea, then at the least can you clarify the warnings of the existing features to the effect of:

"Confirm Starting Over
If you choose to start over, your current website visual design and content will be deleted (any saved snapshots will remain available however).
Are you sure you want to start over?"


"Confirm Removing Website
If you choose to remove this website, you will not be able to restore your current website visual design and content later (including all saved snapshots).
Are you sure your want to remove this website?"
(Please note that your site will remain published online in it's current state)

All of that said, I keep forgetting to mention the most obvious confusing element in this Version Control discussion is the term 'Snapshot' itself. I know 'snapshot' is a common IT industry term (such as a database snapshot is a true backup save that includes the actual data), but the type of users working with a fully hosted, drag-and-drop, easy site creator generally don't know that. Doesn't it make more sense to use the term 'Site Version' rather than 'Site Snapshot'? Even if the user base is quite diverse, as you've mentioned previously, and a significant portion is actually familiar with the term 'snapshot' it certainly wouldn't hurt anyone to make it even MORE obvious. Definitely worth your consideration...
 
Last edited:
I would also like to see some enhancements to the "Site Specific" and "Page Specific" areas to improve their visibility. I have had a number of users who has mistaken embedded content in the Site Specific area with out even realizing the feature existed. The feature itself is a good idea it just need to be made a little clearer somehow.
 
Back
Top