Hi, With regards to the beta API perhaps being related to the active work on it here is an update: Over the Christmas week we were not working on those pages. In that period the overall access percentage went from 5% of our site hits to 15%.
I think the pinch of salt got smaller, Andy On Wed, 20 Dec 2017 at 02:13 Carsten Haitzler <[email protected]> wrote: > On Mon, 18 Dec 2017 12:23:08 +0000 Andrew Williams <[email protected]> > said: > > > Hi all. > > > > Since adding Google Analytics a while back I have some interesting > > statistics that I thought I would share: > > > > 1) Very few people read our Stable API documentation - around 0.5% of our > > page hits > > 2) Over 5% of the page hits are already for the beta API documentation > > I'm willing to bet that this is mostly because of the work going on on > these > and "checking the work when done" etc. and not "real traffic". At least > until > this settles down I'd take these numbers with a grain of salt then look at > again. > > > 3) Most of the hits to /docs seem to result in a referral to /develop > > 4) Nearly 40% of people landing on our home page leave right away > > Not surprising. enlightenment is a common word. > > > 5) Terminology is the most popular app (by page hits) and Edi is second > > (1/4 times the hits) then ephoto (1/4 again) > > Also not surprising. :) > > > Not all of this requires any action but here is the action plan: > > 1) I am not intending to put any further effort into our legacy API other > > than the extraction of eina and eo for the Beta API docs > > Like others said. I think this might be a mistake. The legacy API is going > to > be around and supported for years to come. Sure. eo/eina is important in > where > we're going, but the legacy docs maybe should at least just be made to be > "not > broken" as much as is sanely possible. Not saying we should go WRITE more > docs > there... That's all. Unless this is what you had in mind? > > > 2) We can expect more people to be trying to use our Beta API - do we > need > > to prepare for this or should we put up more obvious warnings about > > attempting? > > I thought the need for a #define to enable them was enough... perhaps some > more > #warnings IF that define is set AND it's not the efl build itself... ? I > still > think it's far too early to stabilize any of this. Even futures are still > "not > done" and in flux. As is ecore (efl loop and friends/related). > > > 3) I think it is time that the main "Develop" link goes to the /develop/ > > dokuwiki. The link to phab exists on the /contrib page where it belongs > > I guess that depends on the interpretation of "Develop". Developing as in a > USEE of EFL libraries and their APIs, or developing as in working on > E/EFL/etc. > and EFL API's. It's a fine distinction. > > > 4) We should find a way to make our home page more appealing - when > loaded > > on an average monitor you need to be full screen to see anything more > than > > the "Window manager" section. > > Indeed it could be nicer. Using a wiki limits our formatting abilities as > it's > simpler. I would have just had large screenshots of lots of stuff to start > with > instead of text as really "oooh aaah pretty images" really works. At least > "front and foremost". But I'm holding off on doing this until flat theme is > done. At least then it'll be "oh finally they're flat" reactions. > > How to present those screenshots... that is in and of itself a good > question. > like a big horizontal banner then with a small bit of text (and links) > below, > one after the other? One of those lightbox things that keeps flipping > multiple > images with some js (would need a wiki plugin). for some things videos or > animated gifs might actually be the best as the wow factor is in watching > it > move and react. Yes - it's a bandwidth hog, but it should have a huge > impact vs > stills. Perhaps again - a wiki plugin with a "still image" until you > mouseover > or maybe click/tap then the video/animated gif is loaded and plays? I don't > know. just trying a more concrete idea "float". > > > 5) For our about page we may need to tell a better story about how it all > > fits together. Otherwise it's E & EFL and a list of apps - not the how or > > why of what we are doing... > > Yes. Also the main pages like about need to just have less text and more > pictures. Reality is few will want to go through a wall of text. The wall > of > text should be "further down the line" when they want to dig for info. > > > Please shout if you disagree with any of these action points :) > > > > Andrew > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - [email protected] > > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
