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.
Yes, there is a way to add events directly to your calendar. With version 14 (which is the latest cloud version) we introduced an ICS download which you can directly connect with your calendar application on your computer (or mobile device). There is a brief explanation in this blog article: https://www.coyoapp.com/blog/externe-workspace-mitglieder
We are also working on a direct integration with Outlook in O365 and Google Calendar.
Hey Philip, you mean that users don't have to say whether they attend or not? Could be useful for public events, yes. I'll keep it in mind but it won't have the highest priority here.
Nothing secure - but the plan is to improve a few flaws in the general concept like:
- making it easier to create public / private events
- invite all members of a workspace / subscribers of a page
- edit the admins afterwards and do not display them as hosts
We are planning to do some general improvements for the events - this will be one of them. Unfortunately, we don't have a timeline, yet.
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.
Hey Lazlo, selected user appear in the order you picked them initially - but yes - that's not very convenient.
Please do not link to service tickets here since other user won't be able to read them. Besides, the ticket you linked describes a completely different topic.
I removed the number of the ticket.
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.
Ok, thanks for your feedback!
Hey Nils, you mean having a navigation "A B C ... X Y Z" to page through the pages / workspaces? Neat idea!
I merged this issue. Thanks for pointing it out.
We are thinking about giving users the option to mark workspaces as their favorites. Favorite workspaces will be the first in the list on the workspace overview and in the subscriptions widget.
Hey Ben, cool! I'll merge this suggestion into the other one then.
Yes, the automated approach is great and we considered doing that, but the technical solution is not trivial since it has to be determined for every user independently.
Additionally, users might get confused when the order is changing constantly. It might be easier to understand and simpler to just let them decide on their own.
Hey Ben, thanks for your suggestion and sorry for the very late answer.
We were considering this idea but thought about going with another approach. What do you think about the suggestion in https://community.coyoapp.com/forums/306010/suggestions/17885272 ?
We have the idea of giving users the option to mark their favorite workspaces manually. On the workspaces list and within the My subscription widget we would then list favorite workspaces first.
Would a restriction by file size do the trick as well? Could be way easier than restricting it by file type?!
Hey Andre, I know it's been a while that you created this suggestion. But could you tell me more about the use case? Do you want to restrict this due to the file size of videos or is there another reason?
Sorry, no timeline, yet. But since the file library and the documents app are highly used features they will definitely get an update as soon as we can free up some resources.
Interesting idea. Let's see whether other users would like to see this as well.
We are planning an update with several improvements for events. This is going to be one of those improvements. I’ll keep you posted.
No news, yet. It is still on our roadmap with priority but I don't have a timeline right now.
Thanks for the quick reply and the feedback! We already did some tests with Azure and DeepL - we will have another look into Google as well.
This might be an interesting topic for next year, though. At the moment we are pretty packed with work but we are aware that this would be a great feature!
Hey Stephanie, do you already have a translation engine in place or any preference? Google, Bing, Azure, DeepL etc?
We ware already thinking about that as well. I think that would be a great addition and that feature would totally make sense for the product. I'll keep that in mind and maybe we can squeeze it in at some point.
There is an option to group them for me :) I'll keep them as separated ideas though because marking posts and documents is not necessarily the same
By documents do you mean content in general (like posts, articles etc.) or actual files in the documents app?
Is your suggestion probably related to http://community.coyoapp.com/forums/306010/suggestions/31557100 ?
We still have this feature on our list and it has a medium priority. Unfortunately I can't give you a timing, yet.