4 ms·

+1 for having a usable demo to play with off the bat. I tried to publish a simple page from the demo. But I did have problems: I created a callout, and then

by insky 12y ago

+1 for having a usable demo to play with off the bat. I tried to publish a simple page from the demo. But I did have problems: I created a callout, and then created a page. I then tried to add the callout to the page. And save as published. But I was hit with a message: need to commit first? I didn't get that. I then saved as a draft, and then hit commit. Not sure what was happening. I then tried to view the page, but got a 'No content' message. I then added something to the main content of the page. And saved. No change. I then commited again. But still had the 'no content' message. I then tried the commit and approve, which seemed to finally publish the page. Confusion lies in the commit part, or in the publishing process, order of process. Some buttons looked deactivated, but actually you can click on them, like the 'Commit and approve' button. I was a little perplexed. The demo then reset itself before I could test a form! All feels slow to me. But then again most online CMSs feel a little like that to me. It was also quite difficult dumping widgets into areas. A little practice got there, but it wasn't the easiest of things for me to do.

rockymeza 12y ago
Thanks for the great feedback, I'm so sorry that you got hit by the cron job. > +1 for having a usable demo to play with off the bat. Thanks. The idea behind the versioning system is that for a lot of our clients, the people who are editing the pages are not actually allowed to publish them. Those users will not see a Commit and Approve button, they only have the Commit button. Later, somebody who has full privileges will review the commits (either in the History or in the Review Queue) and decide whether or not to approve those pages. If you wanted to see the version that you were editing (we call it the working copy), you can click on the preview button located next to the Commit and History buttons. You can even test the form from the preview page and it will still work. > Confusion lies in the commit part, or in the publishing process, order of process. I think you are absolutely right that this flow is confusing. We will talk about how to make this flow better and more obvious. > Some buttons looked deactivated I opened an issue for that <https://github.com/fusionbox/django-widgy/issues/205> https://github.com/fusionbox/django-widgy/issues/205>.
- insky 12y ago
  I totally get 'workflow': draft, unpublished, approved, published etc, and 'roles': creators, editors, moderators, publishers etc. I also appreciate the idea of having some version control. With the demo it wasn't intuitive how the above applied to the post, or the creation process. Order mattered, but it wasn't straight forward figuring out the required process. Resulting in frustration. You speak of a staging area, or some such. But how is the user to know about your version control system, or how it works? Surely hitting save should be as good a commit? Or the save implies or triggers a commit? If the commit is that important to the publishing process, emblazen it across the bottom with the Save button. I really just wanted to see how my page looked as early as possible. And be able to see the page before it was published. You should be able to preview content, but make it clear that the status/workflow of the page you are viewing: You could add a banner across an unpublished page with the page status displayed.

by insky 12y ago

rockymeza 12y ago

Thanks for the great feedback, I'm so sorry that you got hit by the cron job. > +1 for having a usable demo to play with off the bat. Thanks. The idea behind the versioning system is that for a lot of our clients, the people who are editing the pages are not actually allowed to publish them. Those users will not see a Commit and Approve button, they only have the Commit button. Later, somebody who has full privileges will review the commits (either in the History or in the Review Queue) and decide whether or not to approve those pages. If you wanted to see the version that you were editing (we call it the working copy), you can click on the preview button located next to the Commit and History buttons. You can even test the form from the preview page and it will still work. > Confusion lies in the commit part, or in the publishing process, order of process. I think you are absolutely right that this flow is confusing. We will talk about how to make this flow better and more obvious. > Some buttons looked deactivated I opened an issue for that <https://github.com/fusionbox/django-widgy/issues/205> https://github.com/fusionbox/django-widgy/issues/205>.

insky 12y ago
I totally get 'workflow': draft, unpublished, approved, published etc, and 'roles': creators, editors, moderators, publishers etc. I also appreciate the idea of having some version control. With the demo it wasn't intuitive how the above applied to the post, or the creation process. Order mattered, but it wasn't straight forward figuring out the required process. Resulting in frustration. You speak of a staging area, or some such. But how is the user to know about your version control system, or how it works? Surely hitting save should be as good a commit? Or the save implies or triggers a commit? If the commit is that important to the publishing process, emblazen it across the bottom with the Save button. I really just wanted to see how my page looked as early as possible. And be able to see the page before it was published. You should be able to preview content, but make it clear that the status/workflow of the page you are viewing: You could add a banner across an unpublished page with the page status displayed.