I remember from observations that one of the biggest problems in the file upload page (esp with multiple files) is that people are actually not able to find the 'Next' button because it is below the fold and sometimes even beyond the right side of the page...
Might be something to check with measuring. The other case we had there is that people do find the next button, but then after pressing it, the script crashes or it became super slow. So a two step measuring might be worthwhile there. On Wed, Jun 4, 2014 at 9:55 PM, Gergo Tisza <[email protected]> wrote: > Hi all, > > we have recently added some funnel [1] logging to UploadWizard. A nice > dashboard is in the works, but here are some preliminary results, showing > the number of virtual pageviews for each step of UploadWizard. > > mysql:[email protected] [log]> select event_step, > count(*), count(*)/3623 as survival_rate from UploadWizardStep_8612364 group > by event_step order by survival_rate desc; > +------------+----------+---------------+ > | event_step | count(*) | survival_rate | > +------------+----------+---------------+ > | tutorial | 3623 | 1.0000 | > | file | 3496 | 0.9649 | > | deeds | 2433 | 0.6715 | > | details | 2373 | 0.6550 | > | thanks | 2109 | 0.5821 | > +------------+----------+---------------+ > > This is based on about a day's worth of logs (25.5 hours) - the logging code > was deployed to Commons yesterday. > > The big drop is apparently in the file upload step (almost 30% - well over > 1000 uploads a day). Some of that might be intentional (upload caught by > badtitle filter etc), but even so the drop is huge. Given that that step is > rather simple from a UX point of view, it seems that upload bugs are a > bigger problem right now than design issues. > (The license selection - deeds -> details - on the other hand is > unexpectedly unproblematic; I would have expected it to be the main source > of confusion, but actually adding description etc. seems worse.) > > The next step would be to log JS/upload errors, I suppose. > Also, it would be nice to know which dropoffs are final and which are > reloads/restarts. The Navigation Timing API can tell apart reloads and > normal navigation, alternatively we could maybe group by IP + useragent + > time bucket to find retries. > > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia > _______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
