SilverStripe CMS iOS/Android App

102 views
Skip to first unread message

Joel Edwards

unread,
Nov 4, 2015, 7:18:26 AM11/4/15
to SilverStripe Core Development
I would like to start a discussion on whether there is a demand for a SilverStripe CMS app and if so, what features it should have. 

AIM
Easily manage your SilverStripe website's content through a mobile app

CONTEXT 
We have the opportunity to kickstart the app with 100 hours of free app development from a app development company based here in London. The project would be started by them and then open sourced for further development by the community. The basic technical approach suggested is for the app to be developed in PHP/HTML/CSS and then put into a native iOS/Android wrapper and published to the relevant stores for free download by either SilverStripe Ltd or the app development company. 

QUESTION
  1. Would you and your end customers use an app to make content edits on a mobile app?
  2. What are the top tasks you would like to achieve on a mobile app?


Colin Richardson

unread,
Nov 4, 2015, 7:31:08 AM11/4/15
to SilverStripe Core Development
1. I think it's a great selling feature and I have, at times, had requirement to do edits on mobile
2. As much as possible! My initial thoughts were mission-critical things like typos / factual errors, but then thought photo uploads from phone too so would want access to uploadfields.

In short, I'm for this.
Colin

James Cocker

unread,
Nov 4, 2015, 12:45:06 PM11/4/15
to SilverStripe Core Development
1. This would be pretty cool, and probably difficult to do well, but I'm sure several of my clients would love such an app.

2. I see ModelAdmin as a good fit for mobile. Making it easy for clients to add/edit/view things like products, availability dates, orders, bookings etc, on the go. Adding things like new Blog posts and News Articles would be next, and while the ability to edit all website pages would be nice, I think the ability for adding/managing new content like those examples is more important/useful.


On Wednesday, 4 November 2015 12:18:26 UTC, Joel Edwards wrote:

off...@netwerkstatt.at

unread,
Nov 4, 2015, 1:32:40 PM11/4/15
to silverst...@googlegroups.com

In fact this kind of app was the only reason for one project to use Wordpress…

 

And it was a major pain.

 

Top tasks would be e.g.

 

·         easy creation of pages / dataobjects, e.g. blog posts, image upload.

·         Editing of pages

·         Viewing Reports

 

 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

Patrick Nelson

unread,
Nov 4, 2015, 1:46:03 PM11/4/15
to silverst...@googlegroups.com
Are we talking about an native app or a mobile version of the CMS? Also, I'm assuming (if web-based) it'd be a move to make it responsive with emphasis on the most commonly used items.

Patrick Nelson

unread,
Nov 4, 2015, 1:50:41 PM11/4/15
to silverst...@googlegroups.com
Sorry just re-read above (I skimmed too quickly). Is there really any advantage to wrapping a 100% web app anymore in a native web-view wrapper? You can pretty easily request that customers/clients simply add a bookmark to their home screen if you wish to have a dedicated icon. It's already inexorably tied to the web so why the extra layer of complexy? I'm not saying it's completely unfounded, I just have no clue what advantage it brings per se.

This empowers the web developer to continue to simply extend the existing web app to emphasize whatever it is that they may need for their particular customers' mobile needs, which will vary. Then, in the broader context, you'd simply initialize with some good sane defaults for editing/uploading/etc. When it comes to the things that this CMS does, there's not much out there that's already doable via the CMS directly within iOS Safari and (presumably) Chrome/Firefox on Android.

Roman

unread,
Nov 4, 2015, 3:30:30 PM11/4/15
to silverst...@googlegroups.com
I have exactly the same feelings about this.

It seems tempting to have a team that creates a mobile app, but what will that lead us to? In the end, are there going to be two different frontends that have to be kept up to date, or that module developers have to care about?

Enabling/optimizing the CMS for mobile use would be much more beneficial in the long run.
Another option I could agree on would be to invest into an API (REST?) that exposes the CMS features. Writing an App that utilizes said API could be a result of this. Developers that write components using React or even a completely separate UI (like a single-page-app) would also benefit from such an API.

But I'm guessing that there's much more than 100 hours of work involved in something like this.

Having an app with some core features of the CMS might sound good to a client at first, but from my experience, clients often need some very customized features and it's going to be a disappointment if these can't be found in the app (especially if they would be simple enough to be used in an handheld format).

Shea Dawson

unread,
Nov 4, 2015, 4:03:13 PM11/4/15
to SilverStripe Core Development
I agree with Banal. How would the app work with modules and customisations that extend the cms interface/functionality? Would developers and module authors be able to easily integrate their extensions into the app? If not, maybe we would be better off with a mobile or responsive web version of the cms that could be full featured?

James Turner

unread,
Nov 4, 2015, 4:56:07 PM11/4/15
to SilverStripe Core Development
I agree with Patrick, Banal and Shea. I can see our clients wanting to edit their websites on mobile though having it as an actual app I don't think is the right approach. It would need to handle the custom features we may have in the CMS plus dealing with a whole different level of device compatibility.

While this custom functionality could be exposed by an API, I still see issues for how someone would even login to the app. You would have to specify the domain, username and password for logging in - so only one extra field here, clients could probably live with that. What if though they have multiple separate sites they manage (I assume they would have to login and logout, could get tedious - a browser could maintain multiple login sessions at once across separate sites) or are using a module like subsites (or multisite)? I can't really imagine something like that being handled by the app in a custom way. Rather than having to modify an API to expose that and have all those extra custom bits in the app itself, use what is already built and accessible in the CMS and make it responsive.

From a maintenance point-of-view, I also don't see the need to also manage a separate codebase for this app when really all you need to do is specify a few extra stylesheets and modify some JS in the CMS (I know that is simplifying the changes required a bit but you get the idea).

To summarise, good idea (CMS editing from mobile) though I don't recommend the "app" approach. :)

Colin Richardson

unread,
Nov 4, 2015, 5:10:46 PM11/4/15
to SilverStripe Core Development
On reflection, I'm in agreement with having the CMS responsive over an app as such. For all the reasons others have given.

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Nov 4, 2015, 6:48:21 PM11/4/15
to silverstripe-dev
Hi Everyone

I am working on a front-end editor for a customer right now (basically allowing the user to edit objects and pages on the front-end).  If I have a chance I will OS parts of this front end editor. 

This module could make it much easier to edit pages and objects using a mobile phone especially if the website itself is mobile friendly.  The way the module works is that you can add an extension and a number of required methods (e.g. fields to exclude, what relations can be edited, etc...) to any DataObject. Doing so will then, automagically, make the DataObject editable on the front-end...

So far the results have been pretty good.

Feel free to ask questions. 

Nicolaas
Reply all
Reply to author
Forward
0 new messages