Hi there, On Mon, Dec 30, 2013 at 9:04 PM, Horn, Julian C <julian.c.h...@intel.com> wrote: > Hi Kenneth, > > We had a similar discussion within the XDK project team when someone wrote an > app that failed to tear down the splash screen and had to wait 10 seconds > until it timed out every time they ran their app in the emulator. It was > REALLY annoying and the user was VERY unhappy.
You can use the same behavior and still show a dialog when using the emulator, pointing out that 3 seconds has done and the splash screen was not hidden and you can even point to documentation. I think that would be a pretty fine thing to do. > I don't think you can argue that the tools produced a good user experience > even though this was the user's own fault. I would like to add that this > happened despite the fact that the emulator's splash screen simulation > contained the following text: Popping up a dialog in the emulator for unexpected behavior (just like Android and other platforms does when apps don't respond) should remedy this. > This is a simulated splash screen I don't see why it would simulate a splash screen that has to be explicitly hidden if the user didn't ask for one. Especially not one that has to be explicitly hidden. A default splash screen is possible but it should then be teared down automatically when the DOM readyState changes to "interactive" (initial layout complete). > The emulator displays splash screen for 10 seconds unless > intel.xdk.device.hideSplashScreen() or navigator.splashscreen.hide() is called As said above, if the user didn't request a splash screen, it should automatically be hidden (on the correct DOM readyState). > Educating non-expert developers is not easy, especially in a world where > nobody reads documentation anymore. Tools can be pretty good at educating and providing links to further documentation. Saying that no one reads documentation anymore is wrong; I know a lot of people reading documentation and I do so myself. > In our discussions we agreed that the emulator did the right thing to > reproduce the behavior one would see on a real device. It was also pointed > out that in most cases the user has taken no explicit action to invoke the > splash screen, yet they inherit a requirement to tear it down. I consider that an implementation problem. > That's inherently error-prone. So far we have decreased the timeout to 3 > seconds, which matches the Cordova default and is less annoying. We're still > discussing what our next step should be. The "New project" templates do > contain code to tear down the splash screen in the deviceready event listener. Just tear it down when the DOM readyState changes to "interactive", but check the current state before waiting for it as it might have passed that state already. > It's not so easy for a tool to tell whether the app is tearing down the > splash screen correctly. I am not saying that it is easy, but it can definitely be done... if it was easy everyone would write such tools and they wouldn't provide much :-) > It's sometimes necessary to extend the splash screen beyond deviceready, so > that can't be treated as an error condition. It's also possible that the user > intends the splash screen to end after a time out; that is, the app designer > may feel that the splash screen cannot stay up any longer even if the app is > not fully initialized. So that's not an error either. A good API is designed such that it is hard to abuse (use the wrong way) and so that it does most most people want (if that makes sense; as people some times think they want to do things that could actually be done in a much better way). I spend many years working on API design both for the web and for C++/Qt so I know many of the pitfalls (can of worms) and we spend lots of time writing (very much read) documentation for our Qt APIs. Btw, if you read the iOS style guides you will see that they discourage the use of splash screens but encourage the use of launch images: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/LaunchImages.html I agree with their reasoning, though I still see the use of actual "splash^^^logo screens" (though not splashy ones) for games etc :-) For this reason I avoid the word "splash screen" and call it [launch] "waiting screen" instead. I have researched the current implementations of waiting screens, the use cases etc and I am currently finalizing a manifest extension together with Anssi Kostiainen (who, like me, is co-editor of the W3C Manifest spec). Kenneth > > Julian > > -----Original Message----- > From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com] > Sent: Monday, December 30, 2013 10:57 AM > To: Horn, Julian C > Cc: Wang, Shiliu; He, Xinchao; Li, Guangzhen; > crosswalk-dev@lists.crosswalk-project.org > Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for xwalk > based application. > > 1) Developers will notice that the splash screen never hides. I think it is > worse that the developer thinks that they are doing things right and cannot > figure out why it takes 3 whole seconds to load their app! > 2) We can most definitely fix in our own implementation. Like store that it > was called and hide when deviceready is called or similar. > > Tools should be written to help with these things ie. the tool can check > whether the hide is being called at the right spot etc and warn if not. A > good tool should do that instead of adding workarounds in the underlying > platform. > > Tools should educate non-expert developers, point out what they are doing > wrong and what they can do better, not trying to cover for their mistakes, > and letting them remain bad/non-expert developers indefinitely. > > If that is not what we are aiming at, the web platform will never succeed as > an alternative to native application development. > > Kenneth > > On Mon, Dec 30, 2013 at 3:56 PM, Horn, Julian C <julian.c.h...@intel.com> > wrote: >> Hi Shiliu and Xinchao, >> >> Here is some rationale for why splash screens need to time out: >> >> Ideally no app should rely on the splash screen timeout. Any amount of time >> you pick will either be too short or too long, both of which are bad. >> Unfortunately, programmers are not born understanding splash screens and >> knowing how to write code that tears it down at the correct time. I hope >> it's obvious that we want to make our tools work well even for non-expert >> programmers. >> >> In the XDK project we have found that developers frequently make one of >> these errors: >> 1) Forgetting to call the API that hides the splash screen. >> 2) Calling the API in a way that doesn't work. For example, in Cordova, >> attempting to call navigator.splashscreen.hide() before the deviceready >> event arrives can fail. Sometimes people put the call after some other code >> that throws an unexpected exception. >> >> If you don't time out or your time out period is long enough to be annoying >> (10 seconds meets this standard), then developers are pretty much forced to >> debug these kinds of errors before they can ship their app. That's a bad >> thing. The default timeout period for Cordova (and for the Intel XDK API) is >> 3 seconds, which seems like a good compromise. >> >> Users that don't really understand splash screens will want to be able to >> change that timeout. If they find the options relating to splash screen in >> the package options, then they will expect to find one that changes the >> timeout. So while I don't think changing the default timeout period is >> really the right approach, I think you should support it. >> >> Julian >> >> -----Original Message----- >> From: Crosswalk-dev >> [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf >> Of Wang, Shiliu >> Sent: Sunday, December 29, 2013 9:49 PM >> To: He, Xinchao; Li, Guangzhen >> Cc: crosswalk-dev@lists.crosswalk-project.org >> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for >> xwalk based application. >> >> Even with splash screen, it has a time limit within which it can help >> improve user experience. A long time waiting with splash screen is also bad. >> So a timeout is reasonable as my understanding. >> >> But on the other hand, the mechanism to dismiss the splash screen >> automatically is very key. >> Have you considered following in addition to the two ways you listed? >> we also provide API to hide splash screen in js just like cordova, as well >> as the api in manifest/package options to turn off automatical dismissing. >> So that, if the developer wants things to be perfect on crosswalk, they can >> use this approach. >> >> Thanks, >> Shiliu. >> >> -----Original Message----- >> From: He, Xinchao >> Sent: Monday, December 30, 2013 10:19 AM >> To: Li, Guangzhen >> Cc: Zhu, Yongsheng; Wang, Shiliu; >> crosswalk-dev@lists.crosswalk-project.org >> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for >> xwalk based application. >> >> "Li, Guangzhen" <guangzhen...@intel.com> writes: >> >>> There are two ways to dismiss SplashScreen in Cordova >>> 1) App developers can decide when close splash screen by js : >>> navigator.splashscreen.hide() >>> 2) By timeout >>> Why we need the timeout, I think it’s the final chance to dismiss the >>> splash screen, when there are some errors occurred on Runtime or Web app. >>> >>> Similar solution for Crosswalk runtime, I think we need to provide >>> two ways >>> 1) When first visible page occurred, dismiss the SplashScreen (By >>> some mechanism in runtime) >>> 2) By timeout >>> Or the timeout can't be configured by the users, Can we make it build-in >>> (few seconds)? >> >> There is another way to achieve this, when finished loading or error >> occurred, dismiss the splash screen, but I really do not think it's needed >> to hide the splash screen when error occurred in Runtime or apps. If using >> timeout, a blank screen might be displayed for a while when loading a huge >> application on a very slow device. >> >>> >>> -----original Message----- >>> From: He, Xinchao >>> Sent: Friday, December 27, 2013 4:37 PM >>> To: Li, Guangzhen >>> Cc: Zhu, Yongsheng; Wang, Shiliu; >>> crosswalk-dev@lists.crosswalk-project.org >>> Subject: Re: [Crosswalk-dev] Intent to implement - SplashScreen API for >>> xwalk based application. >>> >>> For Crosswalk runtime model side, I don't think we need a "timeout" >>> property here, the WRT should decide how long will the splash screen >>> displaying, and for different device, the timeout value should be >>> also different, given a fixed splash screen timeout value is not an >>> acceptable solution I think. >>> >>> >>> "Li, Guangzhen" <guangzhen...@intel.com> writes: >>> >>>> Thanks for your review for Tizen side. >>>> Below is just my draft proposal, need to get more feedback and discussion >>>> from both sides. >>>> The images for xhdpi/hdpi/mdpi/ldpi are both optional in Android. >>>> Agree with you, we can provide only land/port firstly. >>>> >>>> The proposal changed to: >>>> >>>> “splashscreen”: { >>>> “landscape”: “splashscreen_land.png”, >>>> “portrait”: “splashscreen_port.png”, >>>> "timeout": "3000" >>>> } >>>> >>>> I have add another item "timeout" >>>> >>>> Any comments? >>>> >> >> -- >> Best Regards, >> He, Xinchao >> _______________________________________________ >> Crosswalk-dev mailing list >> Crosswalk-dev@lists.crosswalk-project.org >> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev >> _______________________________________________ >> Crosswalk-dev mailing list >> Crosswalk-dev@lists.crosswalk-project.org >> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > > > -- > Kenneth Rohde Christiansen > Web Platform Architect, Intel Corporation. > Phone +45 4294 9458 ﹆﹆﹆ -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆ _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
