Bugs and Suggestions
General discussions, site bug reports and suggestions about the site.
For general questions check out the CodeProject FAQs. To report spam and abuse Head to the Spam and abuse watch. If you wish to report a bug privately, especially those related to security, please email email@example.com
|After an adventurous couple of days, here are some new suggestions for the Article Publishing Wizard:
I'd like to include a reference to the article in the source files; therefore I need to know what the (probable) URL will be before you ask me to upload the ZIP files, so that would be on page 1 or page 2 of the wizard.
(yes, I know, I can always edit it in in a second iteration; that is what I have done so far).
I noticed you don't preserve the order of the uploads; I had them in chronological order (i.e. appearence in the HTML), but you have reordered them and almost made me replace the wrong ones.
One of the most challenging things in article publishing, for me at least, still is deciding in what category and subcategory the article could be stored. This time around, I didn't find anything like "applications" or "tools"; later on I discovered such a subcategory exists under "Web development" which isn't really obvious for me. I'm not sure what the best approach would be, however having the subcategories ComboBox populate depending on the chosen category isn't really helping. At the moment I would go for one large but linear list, with bolded categories.
It isn't completely intuitive how one should go about updating a referenced file, e.g. a ZIP file. I discovered:
a) replacing a file (without a name change) works just like adding one; there is no need to delete the old file, in fact, that fails as the file is locked against the article's content;
b) replacing a file WITH a name change is horrible: one cannot delete the old, as the article still refers to it; so it takes two passes: one to add the new file and update the article content, a second one to delete the obsolete file.
a) deserves better guidance, not sure how b) could be handled elegantly.
Actually, the file deletion (and the final lock check) should be postponed until after the article has been updated. So either one of these scenarios seem reasonable (I prefer the second one):
i. offer possibility to select files to delete, select files to add, as it is now; check file locks and give warning "file XYZ will be deleted provided the article no longer refers to it"; edit article; when done, check the "files-to-delete" list and delete what is no longer needed, give a warning on files (still) locked against the new article, if any.
ii. do not offer a file deletion opportunity right away, just say "file replacement is like file addition; and once the article is edited, you will get the opportunity to delete obsolete files"; offer file addition; then article edit; then offer file deletion, only if there are files that are no longer referenced. This probably results in a page5 to be added.
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
Copyright © CodeProject
All Rights Reserved.