Two weeks ago, the three of us headed out to the FbStart Initiative event in the Impact Hub Seattle. FbStart is a new program from Facebook designed to help early stage mobile startups build and grow their apps. It provides startups with mentorship, community and financial support.
In 2013 Facebook acquired Parse, so a substantial part of the event was actually a deep dive into the capabilities of Parse and how it can help mobile startups to jump start their business. It turned out that the majority of the attendees came for this reason which gave us the perfect opportunity to talk to new and existing Parse users.
With our “user research” we mainly wanted to achieve two goals:
- Get a better understanding of the usage of Parse and the kind of data stored in it.
- Validate the need for an interface to view and manage data.
In the last couple of months we have reached out to over a hundred developers, startups and agencies to learn more about how they use Parse. One of the findings from this early research was that while 400,000 developers are building apps with Parse a big portion of them are actually solo projects or early startups. These developers choose Parse for it’s simplicity and its rich out-of-the box functionality. At this earlier stage the data management is however not as important. Data might not exist yet or at such a small volume that it can just be done by the main developer itself.
These projects become really interesting when they start accumulating a lot of data and the team hires additional members to help with the content creation and data management. At the FbStart event we got the chance to talk to quite a few of these more mature projects. Through these interviews we were able to better understand their data management and the necessity for data interfaces. The two main findings, lack of permissions and Parse’s developer focus, were in line with the insights we obtained from earlier research.
Permissions are crucial
A major concern for bigger teams using Parse are permission controls (see questions about it here, here and here). Parse does a great job when it comes to permissions regarding the end users of the app. Unfortunately permissions don’t really exist for admin users or clients. The only way to do this currently is to invite a collaborator to a project. This allows them to do everything you are able to do with the exception of deleting the app or inviting another collaborator. That means that when a client or a staff member gets invited to an account they are able to view, change or even delete all(!) the data. Additionally they will be able to see and change Cloud Code, Webhooks and Jobs. A CTO we talked to at the event said the following about it:
I don’t want to invite my support team as collaborators because I am too afraid they will delete something by accident.
Another developer told us that they organized a training session with their staff and taught them how to use it and especially focused on what they shouldn’t be doing in Parse. That is just another burden on the developer’s shoulders. It also puts pressure on the staff or the clients since they might be concerned that they could break something by accident.
Adminca addresses this problem with more granular permissions for teams. The admin determines which classes and attributes are visible 0r editable for the team. This feature grants team members access to the data they need to get their job done while preventing them from accidentally deleting data in crucial columns and tables. When sensitive or distracting information is hidden it also helps teams to focus more on the data that is actually important.
The Parse Data Browser is built for developers
The Data Browser in Parse contains a nice amount of features, but it is clear that it was built by developers who had other developers in mind. This was described excellently by an engineer who works for a mobile app agency.
The data browser is great for me, but it’s definitely too complicated and overwhelming for my clients.
Some of the limitations of the Data Browser are:
- The data browser contains all the information that is stored in the application. While that is great for the developer the client really only needs to see a (small) subset of this. ACL, objectId, createdAt and updatedAt are just some of the columns that either are not relevant for the client or don’t even make sense to them. Adminca allows admins to rename classes and attributes as well as hiding any information that is not important for the team.
- The search and filter in the data browser follows a very technical paradigm (searching only through filters) and can easily confuse users. Adminca uses a smart search that helps users to intuitively search by columns.
- The data browser follows a strict table approach. That means it is very easy to compare one attribute across multiple objects but it is much harder to look at all attributes for one object(= one row). Adminca supports the table view as well as the object view. The object view focuses on one specific object and it allows users to look at all the information regarding an object at once, e.g. everything related to a specific user.
- Creating and browsing relationships in Parse follows a developer-centered approach. Objects are only identified through their ObjectId and when a user opens a relationship he is simply brought to a new page. Adminca helps users to reference and identify objects through a natural name field. Relational browsing in Adminca allows users to view the details of a referenced object without losing the context of the original object.
At the FbStart event we also got the chance to meet some of the Parse marketing and product folks. This was a great opportunity for us to learn more about their perspective on admin panels for Parse. One of the things they mentioned was that Parse gets a good amount of request for admin panels. They even showed us a section about it on their Ask Parse Anything segment on Youtube (see video below). With Parse being very focused on the developer experience, we believe that Adminca can be a great, more admin focused addition for mobile startups and agencies. We are excited to launch it soon!
We still have a lot of ongoing user research and would love to talk with you about how you and your team use Parse. Contact us at email@example.com