👉 Question: What are the main pain points you have using Strapi? (Episode 3)

derrickmehaffy commented 3 years ago

As of two years ago the Strapi Chief Product Officer @Aurelsicoko asked the community what their main pain points were and how critical these issues were to the rest of the community.

We again did this in 2020 by asking what your main pain points were.

Once again the Strapi team wish to get the broad community feedback, so the question again this year is: what are the main pain points you have using Strapi?

Please try to be short and to the point and describe your use-case and why you feel this is an important issue.

Instructions

Please only post one pain point at a time.
If your pain point has already been listed, make sure to upvote it instead of posting a similar message. A simple :+1: will suffice.

Template

Issue: Please describe your issue.
Context: Give more details about the use case.

Copy paste the following markdown template:

### Pain point

**Issue:** 
Please describe your issue.

**Context:** 
Give more details about the use case.

We look forward to reading all your comments. All contributions are welcomed, don't be shy 🙈

As a small reminder, we are also working heavily on the Strapi v4 and we have many RFCs (with more coming) on our RFC repo: https://github.com/strapi/rfcs and we have a forum post detailing v4 information here

xBLADEx commented 3 years ago

Pain point

Issue: I wish there was a built-in ready to go WYSIWYG field with everything you need.

Context: This has been one of my top pain points. I've followed several blogs or articles and documentation to add CK Editor and others and it has been nothing short of a headache. Strange errors, things not working, the field not working when not used in a dynamic zone, etc. Sure these might be small gripes but if the system had a nice (maybe even customizable) field for this separate from a markdown-only field I think you would have an easier time with others transitioning to your platform. In short, add this out of the box, the level of effort at least to me was tough and made me want to use something else altogether.

mtrucc commented 3 years ago

Pain point

Issue: Cannot write or update data at one time

Context: https://github.com/strapi/strapi/issues/8089 https://github.com/strapi/rfcs/issues/11 Fake I have 10 pieces of data to update

UPDATE User SET activationStatus = 'active' WHERE id IN(1,2,3,4,5,6,7,8,9,10);

User.update({ activationStatus: 'active'}, {
          where: {
              id: {
                  $in: [1,2,3,4,5,6,7,8,9,10]
              }
          }
      });

I have to use a for loop to recurse, this performance is really bad I read the code, I don’t remember whether you used BOOKSHELF.JS or Knex.js，None of them support bulk operations I once wanted to modify your program or write a plug-in, but I couldn’t keep up with your update speed At first I wondered why you didn’t try to use sequelize or prisma. Later, during the modification process, I found that it was too difficult.

vinodkhandelwal commented 3 years ago

Pain point Issue: Upload large file in chunks

Context: I have a use case where i need to upload large file (order of 10GB). To make it successful i need to upload file in chunks from front end and once all chunks uploaded needs to assemble those in complete file. Currently i am not able to find any handle on how can I handle such a request. I think, formidable has to used for this requirement but not able to find any handle through Koa-body to do so. I am not sure if currently this is doable.

AdrianoCahete commented 3 years ago

Pain point

Issue: Login with Auth0 on Nuxt frontend

Context: I'm creating a service with Nuxt as FE and Strapi as API and tried to use Auth0 as Login Service. Doesn't work because there's no working example or simple documentation that works. I fallback to local just to keep working on the service, but my idea is to move to Auth0 when possible,

AdrianoCahete commented 3 years ago

Pain point

Issue: There's no key/value pair in components

Context: Sometimes I need to have a key/value pair, like a "City" select that can show the value as a "New York" and have the key as a "US_NY" in the code, for example.

Issue: https://github.com/strapi/strapi/issues/7904

Mortalife commented 3 years ago

Pain point

Issue: GraphQL is incredibly slow

Context: I built my frontend using graphql and while testing appeared "performant enough", however, once populated with data and during NUXT static builds, proceeds to cause my server to fall over.

I've experienced OOM errors, and requests taking up to 70s, which ultimately causes the server to be terminated by health checks.

Now to get builds to pass I have to manually scale Strapi before deployment of the frontend to make sure it can handle the build. While there are a few relations between items, it's by no means a huge scale application and I'd expect it to happily run on a 1GB server 1 CPU server, particularly as the hosted DB isn't even blinking at the load.

Mortalife commented 3 years ago

Pain point

Issue: Coupling of the admin and api

Context: While it possible to deploy the admin and api separately with ENV flags it still contains the dependencies of both.

I would have liked to run the api on serverless, and while possible now with increased function sizes, would still benefit from a decoupling of the admin and api dependencies.

In short, the api should be deployable without the admin dependencies (npm localisations etc).

caraie commented 3 years ago

Pain point

Issue: Inconsistent images URI's in development and production.

Context: Images in development points to /uploads/... In production it uses the full URL (e.g. when using cloudinary). When using the APIs, we have to check in the frontend if we are running in dev mode or not in order to replace all the images paths (e.g. inside of a rich text) adding localhost:1337/ if we are in dev, or nothing if we are in prod. Which shouldn't be necessary.

https://github.com/strapi/strapi/issues/4791#issuecomment-850901919

maggie44 commented 3 years ago

Pain point

Issue: Updates workflow for Docker isn't benefiting fully from the power of Docker.

Context: Docker is a brilliant tool for easy deployment, maintenance and upgrade of services. Unfortunately, with the Strapi Docker container, after the initial build of the container future updates have to be done manually. This largely negates the benefits that Docker brings. A container that can be updated with a Docker Pull like many other services in the development community would significantly improve the installation and upgrade workflow.

https://github.com/strapi/strapi-docker/issues/274

maggie44 commented 3 years ago

Pain point

Issue: If you create a field and then later delete that field, it still remains in the API response.

Context: There was some discussion about this in some threads here on GitHub (https://github.com/strapi/strapi/issues/1114#issuecomment-386552097) that suggested it was intentional behaviour for database consistency. For myself, and I am sure many others, popping up APIs can be an iterative process, working out some database structures as you go. Not being able to remove old entries became a real pain, as it meant building the whole instance over again whenever you wanted a different structure (and want to keep a clean API). It also meant that if you delete field, but later add it back in, you experience conflicts preventing that field from being restored.

My experience with this first time around was enough to really make me think twice about whether I would want to go through it again with another instance in the future. I was pulling my hair out when I accidentally added a field with the wrong case ('Field' instead of 'field') and having to start over again for the umpteenth time.

KieranGreenwood commented 3 years ago

Pain point

Issue: Rename collections/components and their fields through the admin UI.

Context: When renaming collections, components or the fields that make them up through the administration, data starts to go missing and things start to break. It would be nice to edit field names and preserve the data attributed to the old name.

mattf96s commented 3 years ago

Pain point

Issue: Inputting relational data on the dashboard if the other relation entry does not yet exist

Context:

I have a collection of categories and a collection of books
I am adding a new book and I realize the relevant category does not yet exist.
I now have to create the book without a category, go make the category, and come back to link the book to the category.

I know it has been mentioned a few times in forums etc., but it would be nice to have a modal or something along those lines..

mattf96s commented 3 years ago

Pain point

Issue: No TypeScript support

Context: I know it has been mentioned as something the team is working on (and I know how difficult TypeScript is to implement for library authors). But it would be such an awesome feature!

WWAZ commented 3 years ago

Pain point

Issue: Relational field > "Custom column names" is not working with MySQL.

Context: I am using a MySQL database. I want to add a relational field called "colormodel" with a custom column name called "colormodel_id". That does not work. In the MySQL table only 'colormodel' appears, not 'colormodel_id'. Effect: It is not possible to save a new state or the select of colormodel relation is empty when editing a collection type.

RolKab commented 3 years ago

I do understand that the primary audience is developers. However, Strapi is often used as a quick way to deploy an admin management portal.

As an admin management portal, the user experience sucks!

Simply put, unless you are a developer, the user experience is not great. However, developers pass it on to some of their clients as an administrator portal and as a client, that experience is terrible.

Please, find a way to inject some user experience into it.

chakritp commented 3 years ago

Pain point

Issue: Cannot seem to separate all strapi related tables (e.g. core_store, strapi_administrator, etc.) into it's own DB while having another DB for all main content and tables.

Context: I'm able to setup multiple connections in my database.js so that one connection is for strapi related tables and another connection is for my main data (i.e. "content"). I am able to set "connection": "content" in all my relevant *.settings.json files and read the data correctly. However, when I want to create, update or delete records, I'm faced with the error: error: select distinct "strapi_administrator".* from "strapi_administrator" where 1 = $1 - relation "strapi_administrator" does not exist

cschweda commented 3 years ago

Pain point

Issue: Updating from one version to another

Context: The big issue for us is updating. I'd like to see a simple update script with each update.

Updates that require a package.json change -- and then a admin rebuild -- are fine. No issues. (Although I take a pre-update snapshot -- just to be safe.)

But updates that require touching the database -- or editing config files -- are more error-prone.

Granted, there haven't been many of these in the past several releases -- but updating (or the potential for complex updates) is always something the prevents me from giving a thumbs-up recommendation for Strapi to colleagues.

I always say, yeah, Strapi is a brilliant way to get a CMS up and running in short order -- except for updating.

Moving forward -- I hope updates will simply involve updating the package.json and then rebuilding the admin.

pr0gr8mm3r commented 3 years ago

Pain point

Issue: UI names are too dependent on the underlying model / components structure, often greatly limiting the possibility to make the admin panel understandable for non-developers.

Context: Places where this is a problem

The "enum names limited by GraphQL" problem is a pretty well known issue of this

But this problem of having names limited by underlying, developer facing values goes further:

I can rename every field of a content type in the CM's display settings, but I can't rename the content type itself (and it's plural for non-English languages, for that matter (strapi/rfcs#18)). This is not really a problem when using self-made models, but for v4 the focus seems to be on plugins and if a plugin doesn't use a name I like I can't customize it
A component's name
The name of a group of components

Why bother?

Internationalization of the admin UI: As a developer I want to program in English (everything else feels so stupid :wink:), but my admin panel users don't speak English. Currently I have a mix of languages, which is pretty annoying to explain for me and confusing to the users.
Being independent of a frameworks/technologies limitations: This becomes apparent when looking at the GraphQL limit on enums. What if there's a new technology that will restrain your character options further? From a user experience standpoint it feels wrong to make the admin panel users follow the conventions of the developer's technologies.

How I'd solve it Add options to configure the displayed names to the already existing "Configure the view" page of the CM and fall back to current behavior when not set. Of course, for component groups it's not quite as easy, because you'd need a place to put the link to configuring the view, which currently doesn't really exist.

amjadniazi48 commented 3 years ago

I am new in strapi, I think for nested categories usually we use one table with id, category_name, parent_id, there must be some treeview, or any easy way to to this. Thanks

KieranGreenwood commented 3 years ago

Pain point

Issue: Reusable components / searchable components

Context: If you have a page collection type with a dynamic zone of components - if you create a component on page1 and want the same component on page2 you have to re-enter the data leading to multiple sources of truth and no easy way of editing the data.

Currently the only means of achieving this that I am aware of are:

Creating a plugin / script to search and update all instances.
Use a collection type and relations but this has downsides such as mentioned above @mattf96s that you have to leave your collection type to create the relation and then assign it.

A desired approach would be to make components more relational. For example: add a "Reusable" Boolean option to all components. Enabling it would add a lookup field to a components form that allows you to search for and use an existing entry or create a new instance with the usual component fields.

wintercounter commented 3 years ago

Pain point

Issue: Filtering/searching using complex queries is extremely slow due to the architecture, especially on larger tables.

Context: I solved this for myself using Elasticsearch, I also made it work through Strapi's GraphQL API. First-class support for Elasticsearch would solve a lot of these problems, and it'd enable a lot of new possibilities for all users.

philippeauriach commented 3 years ago

Pain point

Issue: The admin dashboard is really permissive while the API is totally unoptimized, resulting in very long and poorly performing API endpoint, without the ability to restrict which data we want (a common case is to fetch only a few attributes when getting a list of items, and getting more attributes when getting one item).

Context: Just create a collection with different relations, when you query the collection you'll get just everything, resulting in many sub queries on the database and a lot of fields returned on the client. Works fine when using it with a few items, but is not scalable at all.

pr0gr8mm3r commented 3 years ago

Pain point

Issue: No (unconstrained) nesting of components and dynamic zones.

Context: When I started my project, I didn't think about that limit until I discovered that I can't have nested dynamic zones and components. This even made me consider alternatives to Strapi because I think that modeling my project's structure around this limitation (what I eventually ended up doing) is wrong.

Imagine the possibilities with nested dynamic zones: Column layouts (think of site building capabilities, but not through some half-baked third party plugin like in other CMSs, but native, right in Strapi), Form Input Groups, ...

Also, nesting components more than one layer deep would really level up their usefulness, almost making them like classes/interfaces in object oriented programming: Every component could "inherit" the fields of another.

In many threads I've seen one reason for not having this ability yet are the UI challenges this problem brings with it. With v4 and it's new UI (library) this should really taken into consideration.

KieranGreenwood commented 3 years ago

Pain point

Issue: Fixed admin field sizes and two column layout

Context: Currently the view is fixed at two columns, and fields are fixed at either 50/100% depending on type. 50/50s are forced to flow onto the same line if there is space.

It would be nice to be able to have more control over columns and rows so forms can be displayed in a tidier manner.

pfeilbr commented 3 years ago

Issue:

no serverless pay-per-use self-hosting option

Context:

to make accessible to a broader audience constrained by budget, would be nice to have a serverless pay-per-use option that is cost effective. if not in use/idle, you only pay for stored data (e.g. dynamodb, algolia (search es replacement) and files (e.g. s3)

Skronner commented 3 years ago

Pain point

Issue: Slow restart time.

Context: When working on 'strapi develop', in VSCode, every change in the code takes too long to restart. It would be really nice to be able to restart it faster, because we do this several times a day.

MattieBelt commented 3 years ago

Pain point

Issue: The usage of custom fields

Context: Currently you can develop your own custom field, but you can't add it to the CTB (Content-Type-Builder) field list. This way you can only add the custom field to your model by the settings file. There is also no possibility for backed validation/handling of a custom field.

antosubash commented 3 years ago

Pain point

Issue: Multi-tenancy

Context: From small to big project I think this is a essential feature. All big CMS provide some kind for data Isolation by spliting them as Tenant. It is essential to build a SaaS app. if I make a app with Strapi and I have 3 customers then I need to host 3 instance of strapi which is not ideal for small or mid level organization.

jackHedaya commented 3 years ago

Pain point

Issue: Not being able to customize the primary key type

Context: Currently (as far as I know), there is no way to set the primary key type to UUID or something of the sort in the admin panel. I think its pretty important to be able to choose the id type.

mrboen94 commented 3 years ago

Pain point

Issue: Internationalization cumbersome when many languages are used (especially images)

Context: Images in internationalization can either be translatable or not translatable. If you have an image in a dynamic zone it has to be translatable. So when I was working on a multilingual documentation framework where you have text and images in a dynamic zone, you will have to change every single image in the dynamic zone of all translations when a image is "outdated", since there is no internationalization feature per component in the dynamic zone.

The drawback of making the dynamic zone not translatable is that the text is also affected by this, so you cant have english text below the picture thats universal to all locales.

My request is basically, make localization customizable per component in a dynamic zone and not just the entire dynamic zone. It is the only reason we couldn't go for strapi as our cms.

happyhunter7 commented 3 years ago

Pain point

Issue: Would be nice to have the possibility to remove multiple files only with one graphql mutation but not calling deleteFile mutation in forEach statements for each file((

Context: For example, I have a Carousel with 5 images and I want to delete 3 from there not from the admin panel but from my app as a user.....and I should call deleteFile mutation 3 times to do that.

liamb13 commented 3 years ago

I do understand that the primary audience is developers. However, Strapi is often used as a quick way to deploy an admin management portal.

As an admin management portal, the user experience sucks!

Simply put, unless you are a developer, the user experience is not great. However, developers pass it on to some of their clients as an administrator portal and as a client, that experience is terrible.

Please, find a way to inject some user experience into it.

Could you add a little more to this? I agree the UI isn’t as friendly for clients to plug and play - but isn’t that the pull for Strapi? I hate starting a WordPress site with so many predefined types and menu’s only to find myself using 1/10 of what it offers, and making the rest with plug-ins or custom code.

emahuni commented 3 years ago

Pain point

Issue: Cannot write or update data at one time

Context:

8089

strapi/rfcs#11 Fake I have 10 pieces of data to update

UPDATE User SET activationStatus = 'active' WHERE id IN(1,2,3,4,5,6,7,8,9,10);
User.update({ activationStatus: 'active'}, {
          where: {
              id: {
                  $in: [1,2,3,4,5,6,7,8,9,10]
              }
          }
      });
I have to use a for loop to recurse, this performance is really bad I read the code, I don’t remember whether you used BOOKSHELF.JS or Knex.js，None of them support bulk operations I once wanted to modify your program or write a plug-in, but I couldn’t keep up with your update speed At first I wondered why you didn’t try to use sequelize or prisma. Later, during the modification process, I found that it was too difficult.

I was having the exact same issue. I have a working update that I just modified off Strapi's current version as of writing into my own personal services but wish this could be in this main app. I can create a PR if you guys want it. Sorry for commenting like this, I wanted to put this across here.

emahuni commented 3 years ago

Pain point

Issue: There are bits and pieces of nice code in Strapi codebase itself that are not exposed to userland (developer). It should be a welcome improvement to expose certain functions to assist in creating custom code that works with Strapi without copying or recreating the code where app can reach it.

Context: For instance, the above comment I posted about a certain way the update function works, uses functions such as wrapTransaction, createComponents, updateComponents, pickRelations and so forth, that are key to how I can create my own custom handler of the update function. But I had to copy these small functions from node_modules/strapi-connector-bookshelf/lib/queries.js to be able to use them in userland. If only they could be exposed in the model just like updateRelations is, that would go a long way to help in creating other functionalities and plugins. There is a tonne of such little helpers that should be exposed, I have had such headaches in the past, but this is something that is still fresh since I did this today.

emahuni commented 3 years ago

Pain point

Issue: Wish there was a way to hook into Strapi model engine and also be able to create a global model that is used to extend all models. I always want to be able to add certain common model functionalities or attributes to every model, but doing so is not easy.

Context: For instance, I want to add a working upsert functionality to all models, just like how create or update works and have a way to do something like this: strapi.query('the_model').upsert({...}) or strapi.services.the_model.upsert({...}) or just a common attribute:

"attributes": {
   "deleted_at": {
      "type": "datetime"
   } 
}

But this is not easy because there is no way of hooking up the API at such a level.

This will enable more powerful and meaningful plugins and apps.

nurielmeni commented 3 years ago

Pain point

Issue: Error messages disappear very fast.

Context: I have created custom error with explanation of the error, it displayed only for brief moment, not enough to read it. It would be good that if I hover over the error it will stay visible.

Sascha-Block commented 3 years ago

Pain Point: Asset Management

Issue: At present all media assets are organized in one single upload folder. Formats are not separated, there is NO CARE about meta data at file level at all...

CONTEXT: SINGLE SOURCE PUBLISHING including meta data What media asset concept does strapi follow than? Any API planed that could be reliable for handling of several media assets and it’s meta data?

It should be possible by Strapi core features to allow Strapi user to generate folders within the media library.

According meta data ANYTHING get’s simply lost by file uploads right now… If users plan to set strapi in the role of SINGLE SOURCE PUBLISHING than it would be great to know what to rely on if images, texts and other kind of assets are always based on meta data information...

E.g. if you have an image source with well defined meta data information like image title, keywords, image author and so on than you strapi should take use and care of this value information.

ghost commented 3 years ago

Pain point

Issue: Customizable column names are not possible.

Context: It is not possible to customize the column names to be able to name them differently from the model properties. One of the most common use case for this is using snake_case for database column names and camelCase for model properties (Postgres and MySQL). If fully customizable names are not possible for some reason, at least the snake_case to camelCase conversion should be there to be in line with the most common convention and for better interoperability with other systems (for eg. Spring Boot).

Bookshelf has an official plugin for the same: https://github.com/bookshelf/case-converter-plugin MikroORM does this by default: https://mikro-orm.io/docs/naming-strategy

tsvecak commented 3 years ago

Pain point

Issue: AND filter doesn't work within same relation field.

Context: Unable to filter by multiple values for same relation field. e.g. collection with a relation field of element with many to many trying to query items from collection by

_where: [{ element: 'air' }, { element: 'water' }],

Doesn't return any value, querying different fields AND filter works no problem.

fchristl commented 3 years ago

Pain point

Issue: Polymorphic relations don't work using the content manager plugin

Context: I work on a project where we're using Strapi as a web content management system. We want content stored in different collections for a number of reasons. Imagine a content model like this:

institutions
  |-- Slug
  |-- Description

pages_institution_type_1
  |-- Slug
  |-- Title
  |-- Dynamic Zone

pages_institution_type_2
  |-- Slug
  |-- Title
  |-- Dynamic Zone

Now out of each entry in institutions and the two page collections, we'll generate content pages. As we're generating a website, of course we want to allow editors to create links between pages. As you can see, we need polymorphic relations for that: I might want to link from an institution to a page in pages_institution_type_1, or from a page in pages_institution_type_1 to one in pages_institution_type_2.

We've come up with extensions and workarounds, but would love to have a polymorphic relation picker integrated and working with the content management plugin that simply delivers this feature out of the box.

8byr0 commented 3 years ago

Pain point

Issue: Plugins development documentation is really light and missing exemples / use cases.

Context: Querying content is very well explained and has been improved a lot during past months. On the other side, the plugin / strapi ecosystem is almost not documented. When you want to start developing a plugin and struggle about how to implement things, manipulate UI... The only way to know how the API works is by browsing existing plugins code, strapi helper plugin repo, issues or forum. It's always possible to find solutions but it would be way more faster if doc was as good as the business one. Btw I know V4 is coming and from what's been teased so far it should be better, right ?

derrickmehaffy commented 3 years ago

Thank you everyone for all of the posts (and votes) we will lock this issue in 1 week on August 2nd so we can properly go through and review all the points. If you wish to cast your :+1: on any remaining posts please do so before this date.

I am happy to say that many of the pain points shared will be addressed in our v4 that will go into beta around the end of August.

happyhunter7 commented 3 years ago

Pain point

Issue: No graphql Subscriptions :(

Context: I know it was mentioned a lot of times but it's really important because at the moment the developers should use alternatives like hasura on top of Strapi to properly have Grapql subscriptions out of the box.

I assume it will be hard for you to implement that for all the databases....but at least it should be implemented for most popular databases like postgress which already have a lot of pub-sub libraries that can be used to achieve that faster.

My suggestion is to make this OPTIONAL by default disabled if you guys think that it will affect the server performance.

If you don't have it in the roadmap will be NICE at least a (tutorial/ or page in your docs) explaining how to properly do that by ourselves

benfeather commented 3 years ago

Pain point

Issue: The lack of options to customise the field layout in the admin panel.

Context: I think the admin panel is missing some crucial layout options/components that would help improve the user experience for content authors.

The key changes I would like to see include:

The ability to choose how many columns a field should take up. The two-column layout looks messy and it is hard to create an intuitive layout for editors.
The addition of layout components such as headings, alerts, dividers etc. These components would help break up the content and provide contextual clues for the editor.
The addition of tabs to organise the fields into logical groups. E.g. a tab for page content fields and a tab for SEO fields.

I think CraftCMS and Statamic have good implementations of these features, I have attached some screenshots as an example.

Statamic

statamic_layout-editor statamic_field-layout

Craft CMS

craft_layout-editor craft_field-layout

v4dkou commented 3 years ago

Pain point

Issue: Lack of an API to make Dynamic Zones more visual

Context: I wish you could plug-in your React components for each Dynamic Zone type in Strapi Admin panel.

Strapi is great when it comes to, well, bootstrapping API, but every time we try to use it as advertised (headless CMS), it falls flat with Editor's experience. Our customers do not enjoy figuring out the correspondence between fields and the specific place on the website this content will appear at. Instruction manuals don't help. Recently we've tried https://apostrophecms.com/, and it was exactly what our customers wanted: a visual editor that shows their changes as they will be applied. Developer and DevOps Experience with Apostrophe is lacking, so we are not currently switching to it completely. Besides, Strapi has superior API capabilities. I wish we could use just Strapi, and for this we need to figure out a way to visualize Dynamic Zones.

As Strapi Admin is React-based, it should be easy to plug-in React components that take fields as props.

Yes, if the website is, for instance, being developed with Vue (i.e. Nuxt), it won't be as straightforward as opposed to React-based websites (Gatsby, Preact CLI, Next.JS, etc.). Although, there's always a way, and using Vue->React bridges seems like an acceptable solution, because the performance hit of framework bridging can be disregarded for Admin Panel. https://github.com/akxcv/vuera

jayKeegan commented 3 years ago

Pain point

Issue: Admin panel is unusable on mobile without modifying it manually.

Context: When using the admin panel on mobile the sidebar takes up majority of the screen which makes the UI unusable on mobile. This could be fixed by allowing it to be collapsed, different CSS for the mobile nav, etc.

derrickmehaffy commented 3 years ago

Thank you all for the responses, we greatly appreciate all of the wonderful feedback.

I'm going to close and lock this issue so that our product team can thoroughly review all of the feedback and start creating action items on them.

In reading through the feedback myself I noted that quite a number of the pain points will actually be addressed in our v4 release coming later this quarter so keep an eye out for when we announce our public v4 beta :)

Thank you from the entire Strapi team and remember we plan to do this same issue every year in June, so stay tuned for episode 4 in June 2022.

strapi / strapi