| Announced on | Rollout starts | Rollout ends |
|---|---|---|
| April 27, 2022 | March 21, 2023 | March 31, 2023 |
Starting in Q1, 2023, we’ll be rolling out some changes to pagination in views and the sorting behavior on user profile pages. We are doing this to ensure the future performance and scalability of views, and to improve your overall user experience. This announcement explains what we’re removing and changing, what to expect, and what to do before it happens.
This announcement includes these sections:
- Why is Zendesk making these changes?
- Cursor-based pagination for views
- Changes to sorting user profile pages
Why is Zendesk making these changes?
As explained in our earlier announcement aboutchanges to views sorting and ordering, there are some major infrastructure changes happening in the backend for Views. This is going to make the performance of views more consistent and less reliant on the scale and complexity of the view. Larger active ticket volumes will have less effect on the performance of views. This will also start to open up feedback improvements to the views interface that were previously blocked due to the technical limitations.
Cursor-based pagination for views
Zendesk is supporting a new pagination model calledcursor-based pagination(CBP), and as part of this broader shift, we’ll be switching to cursor-based pagination in views as well. It allows for much faster response times than offset-based pagination at any page depth and improves the overall performance and loading time of the views.
This means that we are removing the ability to skip pages in a view. You will no longer see numbers as part of the page controls such as these:
Instead, each view will include page controls forFirst,Next,Previous, andLast.
What you need to do
We recommend that you create views with multiple, specific parameters to produce more narrowed views that surface more relevant information. For example, if you have a view where you typically skip to page 5 of 10 in order to see tickets assigned to a certain person or group, you can create a new view with an additional parameter for the assignee.
We recommend that if you paginate to find specific sets of tickets that you instead use the Views filtering capability to narrow down to that subset if tickets more easily.
Changes to sorting user profile pages
We will be removing the ability to sort tickets on user profile pages bySubject,Requester, andGroup(seeViewing a user's profile in Zendesk Support). For example, if you click these column headings, nothing will happen. You will still be able to sort by other columns.
What you need to do
Make sure you understand that you will not be able to sort by certain columns on user profile pages in the future. Aside from that, no action is needed.
159 Comments
Awful change! It slows down the work our team does significantly. We can not break down our views to go around this!
Please revert this change! We want less cursor pagination and more manual sort and view options. Ticketing systems are better off when you can edit how many tickets you see per page, filter granularly, and can choose which page to view quickly. Since that's been a possibility for over a decade now, I'm not really seeing an excuse as to why such a large provider is incapable of doing the same.
Removing the ability to skip pages in a view is a terrible change that will make our Zen Desk Administrators have to work harder instead of smarter:
Our team is currently involved in an audit process where we have to look through a few months of closed tickets. Short of creating a new view of our own every time, we've taken to creating our own solved views- since we already can't filter by the date (there are only options like- last three months or in the last year....), we have taken to remembering the page numbers we are on. I'm currently on page 28. Having to scroll one page at a time through those pages is excruciating. Please put the page numbers back in and update your servers instead of making our product more difficult to use.
The changes being implemented now have an extremely negative effect on the productivity of our team. To me, the reasoning behind them cannot be interpreted as an improvement in any way. Removing page numbering is particularly a dealbreaker for us. These are the kinds of changes that may make us look for a replacement for Zendesk as our main contact application in the near future.
It's very disappointing to see that many have already expressed their concerns, and it would be commendable if you listened better to your customers. This is an example of how not to treat your customers, especially for a system that is in the middle of the customer contact world.
PLEASE rethink this... removing functionality that is part of the workprocess of so many customers is very very customer-unfriendly...
Echoing the other comments. If this goes ahead, you have to wonder if Zendesk even bother listening to their customers at all. This really is a poor show. I thought Zendesk was all about making things easier and more productive for the agents using it every day. This goes against everything.
To me, it sounds like your dev team are unable to find a solution to the issue of long load times, causing server instances/processes to stall, and you're basically "fixing" it by removing the feature.
它再一次展示了如何Zendesk doesn't care about their own customers. A thread full of negative feedback and requests not to roll this out, but Zendesk just doesn't care and they do their thing. Pure ignorance!
Taking away needed and useful functionalty for "performance" reasons means you are riding the wrong horse. Fix your performance issues instead...
It was bad enough to see "Subject" sorting go for tickets. Now this wrong decision has reached the last spots and even been extended, to provide a proper "frustration UX" :-(
Oliver
Honestly I'm just getting tired of all this. The Zendesk sales team keeps trying to get us to buy or upgrade our package and at the same time the Zendesk development team keeps REMOVING features. It feels like someone on the dev team was given gun and told to go wild and the sales team was instructed to use that situation as a sales tactic...
Salvador Vazquez
It would be great to have a response from Zendesk regarding the negative feedback in this thread, at the very least to assure customers they have a voice that is heard.
Cursor pagination removing page numbers is a functionality decrease. Zendesk has removed the page numbers but left the existing left/right first/last options. Shaving off load time per page with this change at the cost of skipping specified pages is counterintuitive. Please revert this back to the ability to select pages.
This change has been detrimental for our workflows, particularly for triaging. The ability to jump to a specific page either via UI or by adjusting the URL would be a significant improvement for us. We are also disappointed to see more sorting ability being removed rather than being enhanced through improved filtering UI.
This makes finding tickets extremely difficult, especially if you look away for 10 minutes and can't use the page number you were on as a reference.
This seems like a digression in customer needs, next and last don't help.
Can you build something like from 170 total pages If I want to can enter that page number say 71 and it will take me there ?
Time is money and we don't like this new update by you and it takes a lot of time and effort from going to say page 171 to page 90.
Thank you all for the insightful feedback. I understand it may be frustrating to get functionality removed that you have been used to for so long.
We want to make sure our product scales and performs consistently for all customers, and some of the improvements we have made in order to improve performance and reliability have required trade-offs resulting in some of the functionality that has had to be removed. Most of these trade-offs are expected to be a shorter term challenge, ultimately, it will enable us to add all the great features you are looking for, and to do so at scale.
我想让你知道我们的目标是不让这ngs harder for you, but to create more efficient workflows that scale for everyone. One of the solutions we have introduced to help you work with these trade-offs isIn-Views Filteringwhich offers you a more efficient approach to sorting on a column and clicking deep into the pages to narrow down a list of tickets.
Our plan for the long-run is to make Views a more efficient place to work, but please understand there is a tough transition point here. For those who still have use cases where filtering or creating new views is not enough we would like to offer an option to extend the old functionality temporarily, absolute deadline is end of Q2 23’, as we work together to discuss short and long term options. You can do this by filling out thisform. I look forward to working with you all to create a more efficient experience.
Salvador VazquezIf the goal is not to make things harder but to create more efficient workflows, and with nearly a year's worth of what seems to be universally-negative feedback leading up to the deployment of this change, why was it still rolled out in a state that does nothing but make things harder? Could the team not have taken the time to implement a workaround if not outright alternative functionality, such as a jump-to-page field or the addition of page numbers to the URL, such as on this very support page? How does something as simple and essential as listing page numbers result in such a performance hit that they needed to be removed? What actual progressive changes to views are in the pipelines beyond just "performance"?
Salvador Vazquez stated:
"We want to make sure our product scales and performs consistently for all customers, and some of the improvements we have made in order to improve performance and reliability have required trade-offs resulting in some of the functionality that has had to be removed."
翻译:“我们不关心我们的需要current customers who have been loyally paying many thousands of dollars per month for years. We've decided to sacrifice them in favor of meeting quite different needs of a totally different set of customers we hope to acquire in the future, and/or a subset of some of our existing customers that doesn't happen to include *you*. Nothing personal, just business decisions!"
Thank you for making this so plain, as it is consistent with all of ZenDesk's development decisions over at least the past two years. Our own business decisions become increasingly clear.
This whole thing just looks like someone is trying to generate workload now that pandemic is over and developers in high tech companies are getting released. Let's break and then... kinda... fix. Yeah right, Zendesk functionality has been decreasing during past 12 months. First they decided to move buttons around (merge, report spam and similar) and suddenly something that I used for a decade wasn't in the top right corner, but instead at the bottom. Well guess what, it's far easier to move the mouse vertically than horizontally. Then, IIRC, views in the past used to have auto-refresh so new tickets would show up in the ticket queue without me clicking on that 'refresh' button every now and then (I actually get an email first and then I click refresh). And now this pagination thing that... I just cannot understand how Zendesk product manager doesn't understand why numbers are more efficient than 'fast fwd - rev' kinda tape recorder buttons. We're not retro people when it comes to business, you know?
Salvador VazquezOnce the form is filled out, how soon can we expect the extension enabled?
The long term option considering Zendesk's performance during the last few quarters is pretty clear.
Salvador Vazquezare you serious?
You need THREE Weeks wo answer all this negative feedback. And just say the same nonsense perfomance issue reasons, everybody knows can't be true or even worse, your Zendesk infrastructure is so bad, that even Site Paginations slow down everything so badly you have to change it.
You are Helpdesk company and you are not able to go into your costumer concerns and just want all of your costumers to work like you want them to work with Zendesk. And have you worked with Zendesk by yourself? To be honest I don't think so, there are a lot bigger problems than this.
这里的用户体验extrem bad, I can't even believe it's the UX from an Helpdesk company. If my company would work like this, we would lose so much costumers, that we could close.
And just to say it one more time. It needed three weeks, that someone from Zendesk answered on this topic. It's unbelievable
It appears that many people are using views like a report rather than using them for the purpose of actioning the top most ticket. This is incredibly common and many people prefer views over explore for this purpose as they find it faster.
A report could achieve the need if it does not then identify why and let Zendesk know those specific reasons.
The pagination change has been impactful to some of our team members and required alterations to their workflow to try and keep their productivity up. We understand there's reasons for this change, however we also want to highlight that the functionality of linking to pages directly has been a big step back for us.
Stella KangI just did a bulk update of those who have filled it out so far. You can expect 1-3 days delay between signing the form and having it updated.
We've got the extension already. Never seen my team happier! I really hope that the negative feedback you've got so far makes you reconsider this change. As for the In-Views Filtering, it does nothing for us and cannot be a substitute for the features you've taken away.
HISalvador Vazquez,
I appreciate the reason for the changes and the goal of improved performance - I am hoping with the recently annouced increased views (https://support.zendesk.com/hc/en-us/community/posts/4409217537050-Views-limitation) this will bring improvements.
However, I do believe there remains valid scenarios where some views will have a lot of tickets, resulting in dozens of pages (high volume of tickets from an individual customer). Moving through these pages individually is painfully slow under the new pagination.
Is there any potential of introducing a dropdown where you could select the page you would like to move to at least?
I would also like to mention that Views Filtering is nice, but not near as robust as it could be (allowing the ability to filter on multiple options (multiple statuses / multiple groups / etc.) and only being able to filter on the columns displayed in the view (tags are not a replacement for this, as not every user knows the various different tags in the system). It feels as though thenew Requests Experienceavailable to End-Users has more robust filtering options than the Agent side.
Stephenour company has many tickets in views but we are able to make them work for us. What is the reason you need to go to pages beyond the first?
Does Explore satisfy the need to report on the tickets in the same way your are using views ?
Are you manually assigning tickets rather then letting users leverage the play button?
Does the filtering issue still hold true if the view was not being used for reporting and why?
Why is a user paging through the view shouldn't they be actioning the tickets based on SLA and the default sort order of the view ?
I have been trying to understand this issue and have not seen a user case in this thread other then views are what people are used to and are faster when trying to get data. I agree with these points but is there a use case that you have which would as insight to the issue ?
Te be fair, Explore was not designed for reporting on rows of data (tabular reports). It's primarily designed for aggregating data and calculating metrics. Tables are kind of an afterthought. You'd have to do a hack to get each ticket to show up as its own row, which is not very intuitive at all. Zendesk can either redesign explore or provide a sample report.
Here is a use case for pagination.
Our company has a rather complex product and an extremely wide range of users, from newbies to power-user veterans. Email is our primary support mode, all of which come into the main ZD queue.
As we are growing rapidly, the support team also has a wide variety of knowledge. Nobody knows everything (and never will), and there is a constant influx of new hires who know relatively little.
It would be impractical to not let them work tickets until they know a great deal. So instead we concentrate on training the basics and how to accurately determine what they do and don't know.
Yes, we do generally work from the oldest tickets forward, but, new hires know to just skip things they don't know and keep moving forward until they find one they do know, generally something that can easily be answered with a reference to the right support doc. Naturally, more complex tickets will pile up at the back until more senior staff can get to them, and either answer or escalate.
So, it is common for the most junior staff to work a page or two in from the back, because everything older than that is beyond their competence, but nobody senior enough to determine their proper disposition has yet had a chance to review them.
Ken TaylorThat sounds like the users are opening the ticket triaging it to see if they can work it then placing it back in the group to have actioned by someone else. If this is the case then why wouldn't they tag it in some way to allow it be identified as complex so it can be hidden from the view Simple /Triage view. Have a second view that the senior users action as a priority and if it is empty then they can pull from the Simple /Triage view.
这将solve the use case and allow the view to be used more effectively while giving you reporting on which tickets are them more complex ones. You could also use these metrics to build knowledge base articles or process/procedure for the more complex issues so that new users would be able to reference and action more issues in the future.
Pleasesign into leave a comment.