Hey Anne, thanks for your suggestion. That's not possible right now but I'll leave this suggestion open so other interested customers can vote for it.
Can you tell me a bit more about the use case? What should happen with archived form entries? Is it simply a graphical thing?
we are upgrading the emoji picker to feature more emojis and also show a list of lately used emojis. Would that be sufficient for your case?
Hey Josephine, I know this has been the case in COYO 3 but whats the actual use case for this? In my opinion people are used to insert emojis directly by now instead of using characters. And people who choose to use the character version are mostly annoyed if those get "translated" automatically?!
I am personally not a big fan of comments of comments. But what about a feature to answer to comments (like in WhatsApp) or easy quoting comments?
In COYO3 we experienced that hardly anyone really understood the "Top posts" filter and it does not really help with the use case of coming back from holidays.
I like the idea having filters on the timeline, though. Let's see whether other customers are voting for this idea as well.
@sarah: Thanks for your ideas. With the next cloud and enterprise release we will replace links with a button again. So, here we will provide an improvement. Sharing of list items with a preview picture could be quite difficult since there might be 0, 1 or multiple images in on entry - but I still think the idea is quite interesting. We'll take this (together with preview pictures in the list entry) into consideration.
@mark: Thanks for your reply. I'll put your suggestion on our internal roadmap.
I guess you are using the blog app instead of the list app for this since it looks nicer, correct? I am just asking because I know that other customers are rather using a timeline or list app for providing a marketplace.
But regarding your suggestion: would it be sufficient for your use case to add a setting to the blog app that allows users to only edit / delete their own blog articles? Or would you actually need a dedicated app for this?
Deleting images attached to a blog article is (by concept) not possible right now. Because admins could use those images at any other place as well and this would break those links.
That would add quite some complexity to the configuration of the form app. But generally I'd agree that it is waste of space to put 3 checkboxes in columns on their own.
But we'd rather find a solution to improve the widths of the columns to solve this. Would that also be sufficient for your use case?
It would fit into the product and would be a nice feature. Unfortunately, I can't give you a timeline on this because there are many other features with a higher priority right now.
Can you provide a use case? What would this be helpful for?
We are going to make it possible to remove and add new attachments within the “Edit post” dialog.
Hey Christoph, this is still planned but I don't have a timeline, yet.
for ordering uploaded files see: https://community.coyoapp.com/forums/306010/suggestions/36050935
There is also a suggestion for making posts editable entirely:
Hey Thomas, can you tell me a bit more about the use case? Why exactly do you need this?
This is an ongoing discussion for a very long time. There are advantages and disadvantages of having this button.
On the downside users may not understand the concept or simply don't see the button and therefore miss new posts. Additionally, it seems like an unnecessary click for a user.
On the other hand it gives a user control over when to read the new posts and once the concept is understood it is very simple. If posts would simply be displayed without any action the user also might get confused for several reasons:
- the timeline might "jump" because new items are added
- the user might miss new posts because he or she scrolled down and a new item was added during this time
- new items came in during a reload by the user
- a user was on holidays and has 100+ of new posts.
With clicking the button it is clear what a "new" post means. When new posts come in every time when should the "new" badge be removed for older posts?
I personally would vote FOR the button and against removing it because it is a concept that users learned to use for years now and because it makes things clear and simple.
Although, I'll leave this discussion open because I am very interested in what other people think and what ideas are out there that might be better than the button.
Thanks for you response! I edited the title to make it clearer for others to understand. Let's see whether other customers have the same need and vote for it.
Hey Thomas, do you mean a field that automatically increments the number?
I merged these 2 suggestions since they are connected to each other. I like the idea of colleagues being notified if there is a major change / update on a wiki article that others should be notified of. Also there should not be a notification if it is just a minor change.
Thanks for this idea. After we released the new launchpad we will have a look into it.
We are working on a major improvement of the launchpad. We are not planning on adding a widget, though.
But generally: what's wrong about the fullscreen?
Isn't that a bit too much considering that timeline posts are usually done for collaboration / communication of users. I am rather sceptical that we should add so many options to timeline posts.
Hey Christoph, I'd need a little bit more info. What's is the use case? Do you would like to schedule posts for the future or change the date to any time / day?
Hey Christoph, good point. Landing pages might be hard to find with the current search algorithm since they don't really contain a lot of searchable content - also they won't be listed in the quick entity search.
We'll keep that in mind for the next optimizations. Right now we are gathering some feedback about the latest changes.
Hey Benny, thanks for the suggestion. I have to admit that it can be confusing that a document is found in the search that actually might not contain the searched term because the word only appeared in an older version.
This works as intended, though. In many cases old versions of a file point to newer versions. E.g. a weekly meeting report is saved in COYO and a new version is uploaded every week. Now this meeting get renamed - in this case it would be great to be able to find the document with the old AND the new name.
@Christoph: This doesn't really work with our concept of a general file library. For a file (and therefor the search) it doesn't matter whether a file is visible or not. Also, in many cases you still want to be able to find the document within the search even if it is not visible in widgets.
Hey Christoph, that is unfortunately true for some contents - for some others we have readable URL, though. But in general I agree. We should improve the integration of analytic tools, e.g. by providing more and better readable URL.
I just wanted to state that our general strategy here is that we won't build an analytics tools within COYO. We should rather focus on integrating the existing (and great) tool which are already out there.
Thanks for your feedback, Oliver! I would rather keep the administration of this feature easy (just add it on a page level) but apart from that I think this is a great idea
Tools like Analytics and Matomo are actually pretty good and should be used to track and analyze contents. But I like the idea of showing the views of an article publicly (can be enabled / disabled) to all users.
Thanks for the hint. Yes, being able to sort users in the admin by different categories would be quite helpful. I don't really agree with the second link since it would need a change in the general concept. I'd like to keep the page administration within the pages.
Hey Christoph, thanks for your feedback. It's very valuable for us especially for new features like the external workspace members.
I agree that it could be more convenient to administrate externals. We'll have a look into it.
Fair enough ;)
Yes, using the sticky function for posts might be a bit too much for this. It's probably enough to be able to pin posts (manually or for a certain amount of time),
Hey Christoph, if the option is enabled that blog articles get shared automatically you could additionally check an option within the article to make the article sticky. But after I thought about it for a while this is probably not the best usability since options to share articles and make articles sticky would be placed at very different locations.
So maybe it would be better to make blog articles sticky within the blog app (as Isabell stated as well).
This is not planned right now. For clarification: should the share article be posted as a sticky timeline item (like in the workaround). Or should an article be displayed sticky in the blog app?
My suggestion would be to allow editors to make the automatic share (which can be set in the blog app) sticky for selected articles.