Recherche avancée

Sur d’autres sites (6316)

• Piwik 1.12, New Features, API Improvements, Stability — The Last Piwik 1.X Release

  30 mai 2013, par Piwik team — Development

  We are very excited to announce the immediate availability of Piwik v1.12 !

  • Download Link
  • How to update Piwik ?
  • List of all tickets closed : Changelog

  Piwik v1.12 is a major new release with four big new features, seven smaller new features, several API improvements and all together 82 tickets fixed. This is also the last major 1.X release, which means after this release we will be working on releasing Piwik 2.0. This also means that you should upgrade to PHP 5.3 or higher if you haven’t already, since Piwik 2.0 will only support PHP 5.3 and above.

  Finally, this release contains two breaking changes to the API. If you use the Piwik API click here or scroll down to see if you’re affected.

  Table of Contents :

  1. New Big Feature – Beta Release Channel
  2. New Big Feature – Segment Editor
  3. New Big Feature – Page Speed Reports
  4. New Big Feature – Device Detection Reports
  5. Other Improvements
  6. API Changes and Improvements
  7. What we’re working on
  8. Participate in Piwik
  9. Summary

  New Big Feature – Beta Release Channel

  

  For those of you who want to help test Piwik 2.0-beta releases as soon as they come up, we’ve made it easier to use our beta releases. Navigate to the Settings > General Settings page and click the The latest beta release radio button. You will then be able to upgrade to beta releases.

  This isn’t truly a major feature, but we think it’s just as important because it will allow us to create more beta releases and thus catch more bugs before we make a final release. This means more releases and more stability for you.

  New Big Feature – Segment Editor

  

  The Segment Editor is a long-awaited new feature that allows you to view, save and edit your segments.

  Piwik has supported segmentation (filtering visits and reports by arbitrary criteria, like browser family) for quite some time now, but it has never been possible to visually create and modify them. Nor could they be saved for later recall.

  Thanks to the eighty individuals and company who funded this feature, it is now possible to :

  • visually segment your visitors, instead of creating URLs.
  • save segments and easily switch between them, instead of remembering URLs.
  • get suggestions for segments that might be helpful to view.
  • learn more in the Segmentating Analytics reports user documentation..

  New Big Feature – Page Speed Reports

  You can now see how long it took your webserver to generate and send pages over HTTP through the new Avg. Generation Time metric.

  This metric can be viewed on both the Pages and Page Titles reports :

  

  And the average page generation time for all the pages in your website/webapp is displayed on the visitors overview :

  

  You can use this new information to benchmark your webapp and web server.

  New Big Feature – Device Detection Reports

  Piwik 1.12 also includes a new plugin that provides reports on the device types (tablet, desktop, smartphone, etc.), device brands (Apple, Google, Samsung, etc.) and device models (iPad, Nexus 7, etc.) your visitors use to access your website :

  

  The new plugin also enhances Operating system detections (detecting sub versions of Linux, Windows, and more).

  Note : This plugin is not enabled by default, but will be in Piwik 2.0. If you want to view these reports now, you can activate the plugin in the Installed Plugins admin page. Navigate to Visitors > Devices to see the new reports. You may also use the new (beta) ‘Device type’.

  The new plugin was developed with the support of Clearcode.cc our technology partner

  

  Other improvements

  Majestic SEO Metrics

  

  We’ve added two new SEO metrics to the SEO widget, both of which are calculated by MajesticSEO.com. These metrics will tell you the number of external backlinks (the number of links to your site from other sites) and the number of referrer domains (the number of domains that link to your site).

  We thank the team at Majestic for their support and hard work in bringing you these metrics to your Piwik dashboards !

  Real-time Visitor Count Dashboard Widget

  

  There is now a simple new widget you can use to see the number of visitors, visits and actions that occurred in the last couple minutes. We call it the Real Time Visitor Counter !

  New segment parameter : siteSearchKeyword.

  There is now a new segment parameter you can use to segment your visits : siteSearchKeyword. This parameter will let you select visits that had site searches with a specific keyword.

  Ignore URL letter case when importing log files.

  We’ve added a new option to the log import script, –force-lowercase-path. When used, the importer will change URL paths to lowercase before tracking them. This way http://domain.com/MY/BLOG will be treated the same as http://domain.com/my/blog.

  Updated ISP Names

  

  We’ve also modified the Providers report so prettier and more up-to-date names of ISPs are displayed.

  Customize the background/text/axis color of graphs.

  

  It is now possible to change the background color, text color and/or axis color of the graph images generated by the ImageGraph plugin. To access this functionality, use the following URL query parameters when generating an image :

  • backgroundColor
  • textColor
  • axisColor

  For example :

  http://demo.piwik.org/index.php?module=API&method=ImageGraph.get&idSite=7&apiModule=UserSettings&apiAction=getBrowser&token_auth=anonymous&period=day&date=2013-03-21,2013-04-19&language=en&width=779&height=150&fontSize=9&showMetricTitle=0&aliasedGraph=1&legendAppendMetric=0&backgroundColor=efefef&gridColor=dcdcdc&colors=cb2026

  Send your users to a custom URL after they logout.

  If you manage a Piwik installation with many users and you want to send them to a custom page or website after they log out of Piwik, you can now specify the URL to redirect users after they log out.

  API Changes and Improvements

  BREAKING CHANGE – renamed segment parameters.

  The following segment parameters have been renamed :

  • continent renamed to : continentCode
  • browserName renamed to : browserCode
  • operatingSystem renamed to : operatingSystemCode
  • lat renamed to : latitude
  • long renamed to : longitude
  • region renamed to : regionCode
  • country renamed to : countryCode
  • continent renamed to : continentCode

  If you use one of the old segment parameter names, Piwik will throw an exception, so you should notice when you’re using an old name.

  BREAKING CHANGE – changes to the input & output of the Live.getLastVisitsDetails method.

  The following changes were made to the Live.getLastVisitsDetails API method :

  • The method no longer uses the maxIdVisit query parameter. It has been replaced by the filter_offset parameter.
  • Site search keywords are now displayed in a <siteSearchKeyword> element. They were formerly in <pageTitle> elements.
  • Custom variables with page scope now have ‘Page’ in their element names when displayed. For example, <customVariablePageName1>, <customVariablePageName2>, etc.

  Filter results of MultiSites.getAll by website name.

  It is now possible to filter the results of MultiSites.getAll by website name. To do this, set the pattern query parameter to the desired regex pattern.

  Get suggested values to use for a segment parameter.

  The new API method API.getSuggestedValuesForSegment can now be used to get suggested values for a segment parameter. This method will return a list of the most seen values (in the last 60 days) for a certain segment parameter. So for browserCode, this would return the codes for the browsers most visitors used in the last 60 days.

  Use extra tracking query parameters with the JS tracker (such as ‘lat’ & ‘long’).

  We’ve added a new method to the JavaScript tracker named appendToTrackingUrl. You can use this method to add extra query parameters to a tracking request, like so :

  _paq.push(['appendToTrackingUrl', 'lat=X&long=Y']);

  What we’re working on

  As we said above, Piwik v1.12 is the last in the 1.X series of releases. This means we are now officially working on Piwik 2.0.

  Piwik 2.0 will be a big release, to be sure, but it’s going to bring you more than just a couple new features and a bag of bug fixes. For Piwik 2.0 we will be revisiting the user needs and the ideals that originally prompted us to create Piwik in order to build our vision of the future of web analytics.

  Piwik 2.0 won’t just be a bigger, better web app, but a new platform for observing and analyzing the things that matter to you.

  Participate in Piwik

  Are you a talented developer or an experienced User Interface designer ? Or maybe you like to write documentation or are a marketing guru ?

  If you have some free time and if you want to contribute to one of the most awesome open source projects around, please get in touch with the Piwik team, or read this page to learn more…

  Summary

  For the full list of changes in Piwik 1.12 check out the Changelog.

  Thank you to the core developers, all the beta testers and users, our official supporters, the translators & everyone who reported bugs or feature requests. Also thank you to softwares we use, and the libraries we use.

  If you are a company and would like to help an important project like Piwik grow, please get in touch, it means a lot to us. You can also participate in the project —

  –> if you like what you read, please tell your friends and colleagues or write on your website, blog, forums, stackoverflow, etc. <–
  

  Peace. Enjoy !

• WebVTT Discussions at FOMS

  18 décembre 2013, par silvia

  At the recent FOMS (Foundations of Open Media Software and Standards) Developer Workshop, we had a massive focus on WebVTT and the state of its feature set. You will find links to summaries of the individual discussions in the FOMS Schedule page. Here are some of the key results I went away with.

  1. WebVTT Regions

  The key driving force for improvements to WebVTT continues to be the accurate representation of CEA608/708 captioning. As part of that drive, we’ve introduced regions (the CEA708 “window” concept) to WebVTT. WebVTT regions satisfy multiple requirements of CEA608/708 captions :

  1. support for rollup captions
  2. support for background color and border color on a group of cues independent of the background color of the individual cue
  3. possibility to move a group of cues from one location on screen to a different
  4. support to specify an anchor point and a growth direction for cues when their text size changes
  5. support for specifying a fixed number of lines to be rendered
  6. possibility to specify which region is rendered in front of which other one when regions overlap

  While WebVTT regions enable us to satisfy all of the above points, the specification isn’t actually complete yet and some of the above needs aren’t satisfied yet.

  We have an open bug to move a region elsewhere. A first discussion at FOMS seemed to to indicate that we’ll have to add syntax for updating a region at a particular time and thus give region definitions a way to be valid only for a certain time frame. I can imagine that the region definitions that we have in the header of the WebVTT file now would have an implicitly defined time frame from the start to the end of the file, but can be overruled by a re-definition anywhere within the WebVTT file. That redefinition needs to provide a start and end time.

  We registered a bug to add specifying the width and height of regions (and possibly of cues) by em (i.e. by multiples of the largest character in a font). This should allow us to have the region grow/shrink around the region anchor point with a change of font size by script or a user. em specifications should also be applied to cues – that matches the column count of CEA708/608 better.

  When regions overlap, the original region extension spec already suggested a “layer” cue setting. It will be easy to add it.

  Another change that we will ultimately need is the “scroll” setting : we will need to introduce support for scrolling text down or from left-to-right or right-to-left, e.g. vertical scrolling text seems to be used in some Chinese caption use cases.

  2. Unify Rendering Approach

  The introduction of regions created a second code path in the rendering spec with some duplication. At FOMS we discussed if it was possible to unify that. The suggestion is to render all cues into a region. Those that are not part of a region would be rendered into an anonymous region that covers the complete viewport. There may be some consequences to this, e.g. cue settings should be usable across all cues, no matter whether or not part of a region, and avoiding cue overlap may need to be done within regions.

  Here’s a rough outline of the path of the new rendering algorithm :

  (1) Render the regions :

  Specified Region	Anonymous Region
  Render values as given :	Render following values :
  width lines regionanchor viewportanchor scroll	100% videoheight/lineheight 0,0 0,0 none

  (2) Render the cues :

  • Create a cue box and put it in its region (anonymous if none given).
  • Calculate position & size of cue box from cue settings (position, line, size).
  • Calculate position of cue text inside cue box from remaining cue settings (vertical, align).

  3. Vertical Features

  WebVTT includes vertical rendering, both right-to-left and left-to-right. However, regions are not defined for vertical. Eventually, we’re going to have to look at the vertical features of WebVTT with more details and figure out whether the spec is working for them and what real-world requirements we have missed. We hope we can get some help from users in countries where vertically rendered captions/subtitles are the norm.

  4. Best Practices

  Some of he WebVTT users at FOMS suggested it would be advantageous to start a list of “best practices” for how to author captions with WebVTT. Example recommendations are :

  • Use line numbers only to position cues from top or bottom of viewport. Don’t use otherwise.
  • Note that when the user increases the fontsize in rollup captions and thus introduces new line breaks, your cues will roll by faster because the number of lines of a rollup is fixed.
  • Make sure to use &lrm ; and &rlm ; UTF-8 markers to control the directionality of your text.

  It would be nice if somebody started such a document.

  5. Non-caption use cases

  Instead of continuing to look back and improve our support of captions/subtitles in WebVTT, one session at FOMS also went ahead and looked forward to other use cases. The following requirements came out of this :

  5.1 Preview Thumbnails

  A common use case for timed data is the use of preview thumbnails on the navigation bar of videos. A native implementation of preview thumbnails would allow crawlers and search engines to have a standardised way of extracting timed images for media files, so introduction of a new @kind value “thumbnails” was suggested.

  The content of a “thumbnails” cue could be any of :

  • an image URL
  • a sprite URL to a single image
  • a spatial & temporal media fragment URL to a media resource
  • base64 encoded image (data URI)
  • an iframe offset to the media resource

  The suggestion is to allow anything that would work in a img @src attribute as value in a cue of @kind=”thumbnails”. Responsive images might also be useful for a track of @kind=”thumbnails”. It may even be possible to define an inband thumbnail track based on the track of @kind=”thumbnails”. Such cues should also work in the JavaScript track API.

  5.2 Chapter markers

  There is interest to put richer content than just a chapter title into chapter cues. Often, chapters consist of a title, text and and image. The text is not so important, but the image is used almost everywhere that chapters are used. There may be a need to extend chapter cue content with images, similar to what a @kind=”thumbnails” track offers.

  The conclusion that we arrived at was that we need to make @kind=”thumbnails” work first and then look at using the learnings from that to extend @kind=”chapters”.

  5.3 Inband tracks for live video

  A difficult topic was opened with the question of how to transport text tracks in live video. In live captioning, end times are never created for cues, but are implied by the start time of the next cue. This is a use case that hasn’t been addressed in HTML5/WebVTT yet. An old proposal to allow a special end time value of “NEXT” was discussed and recommended for adoption. Also, there was support for the spec change that stops blocking loading VTT until all cues have been loaded.

  5.4 Cross-domain VTT loading

  A brief discussion centered around the fact that the spec disallows cross-domain loading of WebVTT files, but that no browser implements this. This needs to be discussion at the HTML WG level.

  6. Regions in live captioning

  The final topic that we discussed was how we could provide support for regions in live captioning.

  • The currently active region definitions will need to be come part of every header of every VTT file segment that HLS uses, so it’s available in case the cues in the segment file reference it.
  • “NEXT” in end time markers would make authoring of live captioned VTT files easier.
  • If the application wants to use 1 word at a time and doesn’t want to delay sending the word until the full cue is authored (e.g. in a Hangout type environment), we will need to introduce the concept of “cue continuation markers”, so we know that a cue could be extended with the next VTT file fragment.

  This is an extensive and impressive amount of discussion around WebVTT and a lot of new work to be performed in the future. I’m very grateful for all the people who have contributed to these discussions at FOMS and will hopefully continue to help get the specifications right.

• WebVTT Discussions at FOMS

  1er janvier 2014, par silvia

  At the recent FOMS (Foundations of Open Media Software and Standards) Developer Workshop, we had a massive focus on WebVTT and the state of its feature set. You will find links to summaries of the individual discussions in the FOMS Schedule page. Here are some of the key results I went away with.

  1. WebVTT Regions

  The key driving force for improvements to WebVTT continues to be the accurate representation of CEA608/708 captioning. As part of that drive, we’ve introduced regions (the CEA708 “window” concept) to WebVTT. WebVTT regions satisfy multiple requirements of CEA608/708 captions :

  1. support for rollup captions
  2. support for background color and border color on a group of cues independent of the background color of the individual cue
  3. possibility to move a group of cues from one location on screen to a different
  4. support to specify an anchor point and a growth direction for cues when their text size changes
  5. support for specifying a fixed number of lines to be rendered
  6. possibility to specify which region is rendered in front of which other one when regions overlap

  While WebVTT regions enable us to satisfy all of the above points, the specification isn’t actually complete yet and some of the above needs aren’t satisfied yet.

  We have an open bug to move a region elsewhere. A first discussion at FOMS seemed to to indicate that we’ll have to add syntax for updating a region at a particular time and thus give region definitions a way to be valid only for a certain time frame. I can imagine that the region definitions that we have in the header of the WebVTT file now would have an implicitly defined time frame from the start to the end of the file, but can be overruled by a re-definition anywhere within the WebVTT file. That redefinition needs to provide a start and end time.

  We registered a bug to add specifying the width and height of regions (and possibly of cues) by em (i.e. by multiples of the largest character in a font). This should allow us to have the region grow/shrink around the region anchor point with a change of font size by script or a user. em specifications should also be applied to cues – that matches the column count of CEA708/608 better.

  When regions overlap, the original region extension spec already suggested a “layer” cue setting. It will be easy to add it.

  Another change that we will ultimately need is the “scroll” setting : we will need to introduce support for scrolling text down or from left-to-right or right-to-left, e.g. vertical scrolling text seems to be used in some Chinese caption use cases.

  2. Unify Rendering Approach

  The introduction of regions created a second code path in the rendering spec with some duplication. At FOMS we discussed if it was possible to unify that. The suggestion is to render all cues into a region. Those that are not part of a region would be rendered into an anonymous region that covers the complete viewport. There may be some consequences to this, e.g. cue settings should be usable across all cues, no matter whether or not part of a region, and avoiding cue overlap may need to be done within regions.

  Here’s a rough outline of the path of the new rendering algorithm :

  (1) Render the regions :

  Specified Region	Anonymous Region
  Render values as given :	Render following values :
  width lines regionanchor viewportanchor scroll	100% videoheight/lineheight 0,0 0,0 none

  (2) Render the cues :

  • Create a cue box and put it in its region (anonymous if none given).
  • Calculate position & size of cue box from cue settings (position, line, size).
  • Calculate position of cue text inside cue box from remaining cue settings (vertical, align).

  3. Vertical Features

  WebVTT includes vertical rendering, both right-to-left and left-to-right. However, regions are not defined for vertical. Eventually, we’re going to have to look at the vertical features of WebVTT with more details and figure out whether the spec is working for them and what real-world requirements we have missed. We hope we can get some help from users in countries where vertically rendered captions/subtitles are the norm.

  4. Best Practices

  Some of he WebVTT users at FOMS suggested it would be advantageous to start a list of “best practices” for how to author captions with WebVTT. Example recommendations are :

  • Use line numbers only to position cues from top or bottom of viewport. Don’t use otherwise.
  • Note that when the user increases the fontsize in rollup captions and thus introduces new line breaks, your cues will roll by faster because the number of lines of a rollup is fixed.
  • Make sure to use &lrm ; and &rlm ; UTF-8 markers to control the directionality of your text.

  It would be nice if somebody started such a document.

  5. Non-caption use cases

  Instead of continuing to look back and improve our support of captions/subtitles in WebVTT, one session at FOMS also went ahead and looked forward to other use cases. The following requirements came out of this :

  5.1 Preview Thumbnails

  A common use case for timed data is the use of preview thumbnails on the navigation bar of videos. A native implementation of preview thumbnails would allow crawlers and search engines to have a standardised way of extracting timed images for media files, so introduction of a new @kind value “thumbnails” was suggested.

  The content of a “thumbnails” cue could be any of :

  • an image URL
  • a sprite URL to a single image
  • a spatial & temporal media fragment URL to a media resource
  • base64 encoded image (data URI)
  • an iframe offset to the media resource

  The suggestion is to allow anything that would work in a img @src attribute as value in a cue of @kind=”thumbnails”. Responsive images might also be useful for a track of @kind=”thumbnails”. It may even be possible to define an inband thumbnail track based on the track of @kind=”thumbnails”. Such cues should also work in the JavaScript track API.

  5.2 Chapter markers

  There is interest to put richer content than just a chapter title into chapter cues. Often, chapters consist of a title, text and and image. The text is not so important, but the image is used almost everywhere that chapters are used. There may be a need to extend chapter cue content with images, similar to what a @kind=”thumbnails” track offers.

  The conclusion that we arrived at was that we need to make @kind=”thumbnails” work first and then look at using the learnings from that to extend @kind=”chapters”.

  5.3 Inband tracks for live video

  A difficult topic was opened with the question of how to transport text tracks in live video. In live captioning, end times are never created for cues, but are implied by the start time of the next cue. This is a use case that hasn’t been addressed in HTML5/WebVTT yet. An old proposal to allow a special end time value of “NEXT” was discussed and recommended for adoption. Also, there was support for the spec change that stops blocking loading VTT until all cues have been loaded.

  5.4 Cross-domain VTT loading

  A brief discussion centered around the fact that the spec disallows cross-domain loading of WebVTT files, but that no browser implements this. This needs to be discussion at the HTML WG level.

  6. Regions in live captioning

  The final topic that we discussed was how we could provide support for regions in live captioning.

  • The currently active region definitions will need to be come part of every header of every VTT file segment that HLS uses, so it’s available in case the cues in the segment file reference it.
  • “NEXT” in end time markers would make authoring of live captioned VTT files easier.
  • If the application wants to use 1 word at a time and doesn’t want to delay sending the word until the full cue is authored (e.g. in a Hangout type environment), we will need to introduce the concept of “cue continuation markers”, so we know that a cue could be extended with the next VTT file fragment.

  This is an extensive and impressive amount of discussion around WebVTT and a lot of new work to be performed in the future. I’m very grateful for all the people who have contributed to these discussions at FOMS and will hopefully continue to help get the specifications right.