NDT-DEV email list created

[Tiziana Refice <>]

On Fri, Feb 21, 2014 at 5:46 PM, Aaron Brown <> wrote:

I’m not sure about anyone else, but my “best case scenario” would be for the flash client to provide a handful of NDT-specific _javascript_ functions like:

     start_ndt_test([ some set of test options ]);

     get_test_status();

     get_test_results(); 

or, if flash supports doing _javascript_ callbacks, maybe have start_ndt_test take some callback functions (e.g. subtest_finished_cb, test_finished_cb) that are called when certain events happen with the test.

The Flash client already has those (and more) callback functions that can be called from JS.

You can find all of the existing callbacks by searching for NDTUtils.callExternalFunction.

Presumably, with the basic building blocks above, it’d be trivial to write a UI over the whole thing.

Cheers,

Aaron

On Feb 21, 2014, at 7:26 AM, Sebastian Kostuch <> wrote:

Hi,
I'm very happy that my last thoughts were clear to you. Also thank you for sharing your opinion about them.
Of course I could willingly take part in making JS UI better. But to achieve this goal it would be good to make
some common vision of what exact changes would be nice to add to this. It would be very nice to see ideas of
all of you about it. I will also try to produce some description about it in some near time.

Kind regards,
Sebastian Kostuch
 

On 21.02.2014 09:40, Tiziana Refice wrote:

On Thu, Feb 20, 2014 at 1:53 PM, Sebastian Kostuch <> wrote:

Hi Tiziana,

On 20.02.2014 10:12, Tiziana Refice wrote:

Hi Sebastian,

On Wed, Feb 19, 2014 at 1:55 PM, Sebastian Kostuch <> wrote:

Hi Tiziana,
Thank you so much for all your reviews.

Thanks to you for taking the time and making the changes!

 

I have fixed almost all of them. The only one left is with copy function.
This is however related to some another question about current state of UI in flash client (see below).

While working on Issue 115 I have encountered some difficulties with dynamically adding
mx or spark controls (to use ProgressBar during tests and Tooltip in mentioned copy function).
It seems like now it is possible to only add basic flash components from flash.display package
due to lack of mxml file which is responsible for containing info about mx and/or spark
components and creating proper container for such objects (which is rather hard to achieve
in pure AS. Also, such an approach is recommended while making little more advanced GUI).

So my question is if we would need such an approach with moving our GUI information to such mxml file?

Are you talking about this file

https://code.google.com/p/ndt/source/browse/trunk/flash-client/ndt-flash-config.xml?

Unfortunately not. I am talking about user interface markup language file which is part of Flex framework
(detailed information can be found i.e. here).

Which information would you be moving to the mxml?

Simply said when we build our application using Flex we use .mxml files instead of .as (there is also possibility
to join these two solutions. Also, in fact, during compile time all mxml files are transformed into pure AS code)
and here we declare all used UI components (just by adding proper xml tag).
At this moment our NDT flash app uses only components from flash.display package which contains only basic
UI controls (so there is no possibility of using things like ProgressBar, Tooltip etc).
More advanced controls are part of mx.* and spark.* packages . However, to use them our app need to be
exposed within Flex framework (these controls require specific container, more info here - section "Spark containers").
Currently what we have is simply sprite object, on which we put all required components. When it comes to using
mx or spark controls there isn't possibility to add them on sprite (they need to be placed inside mentioned container).
So my question was related to if we want to convert our app from pure AS to Flex code in order to have possibilty
of using wider asortment of UI components.

Also, I believe that portability is very important.

This is why I tried to use as pure AS as possible.

Could you specify which clients we would loose if we implemented the changes that you are describing?

From official Flex website it seems like all clients which can use pure AS can also use app written in Flex.
As I mentioned all mxml code is finally converted to AS one so it shouldn't be problem. However, Flex
as a framework tends to add a lot of rather complex and no such efficient code in generated .as files.

It would probably be good when thinking about making some major improvements to UI but if we think
about flash client as background for UI created in HTML and JS then it doesn't seem to be key feature.

This is a question still under discussion.

One one hand is nice to have a self contained client.

One the other hand, having a very basic Flash UI and a fancier UI in JS is definitely a valid alternative.

What's you opinion about this?

In fact, I was thinking that the purpose of developing flash client was to exchange it with current java applet
which is also a background for JS code due to java applets being removed from browsers (I am according to M-lab released version).
If we think about it this way about it then it's rather enough to have flash app using only basic UI. But then we need
to accept that adding things like animated bars, tooltips, scrollbars etc would be rather difficult compared to making
same things in Flex. On the other hand Flex is less efficient than pure AS (I don't know exact numbers however).

I think that in such applications as NDT flash client GUI isn't key thing and user UI experience could
remain as it is (maybe just change some little things to make it even better, but overall layout doesn't need
such a big improvement, especially that java applet which we have till now also isn't very complex when it comes to UI).
In my opinion Flex is excellent solution when making applications where interaction user-app is very important
and quite often used. In our app all we need is just letting user start test and display results to him/her.

However, if we want things such as visible scrollbars and/or animated progress bars then I will propose
to just create mxml file with minimal required code and convert Main class from the one extending Sprite
to some spark/mx container such as Application. To achieve this we can do something similar as is proposed here.
Also then whole GUI class should be little changed to not use sprite.

Based on all you said above, I believe it makes sense to keep the AS code as simple and as efficient as possible and implement any more complex UI in JS.

Would you have time and interest to work on the JS UI? 

Personally, I would like to at least avoid to have in Flash UI features that would affect the accuracy of the client (i.e., all the features that need to be updated while the test is running).

In particular, I am concerned about the progress bar.

I think that, unless we move to Flash multi-thread, the progress bar should not be implemented in AS.

My idea was not to update progress bar on live but just changing its status after completion of specific
test or part of this. 

I have pushed changes on FlashIssue115 branch where there is just simple plain text
indicating percentage of tests completed. Such an update wouldn't be performed often so in my opinion
we don't need separated thread here. What do you think about such a solution?

Ok. Sounds reasonable. I will provide more specific feedback once I review the code.

 

However, this is just my personal intuition.

If you have numbers that show the impact of having such UI feature in AS,  I would be interested in them.

If the answer is positive then it would probably be good to create separated issue related to it and
as a temporary solution what do you think about:
1. Simplifying progress bar to only show percentage of completion as plain text without ProgressBar control
2. Moving copy button at the bottom of text console (which will be shorten a little in height). Would
it be more intuitive?

I don't see a great advantage of having the copy button (without any kind of feedback to the user), compared to just have the user select and copy the text "manually".

I just wanted to keep flash client consistent with Java one. In latter we have already separated button to copy results to clipboard.
However, if you think that this change is unnecessary then I will of course accept it :). Also I have updated changes on
FlashIssue114 branch and made copy button more intuitive. Feel free to review. 

I will review the code and let you know. 

The latter seems much more intuitive.

I hope my thoughts are clear. If not, feel free to ask any questions :)

Speaking of UI changes, have you looked at the possibility to add a scroll bar to the result tabs?

Currently it would be rather difficult as there is no UI component in basic flash ones that would
perform this role. Of course there is possibility to write manually AS code which will display such scrollbar (probably as image/sprite)
and code its behaviour. I can't tell exactly how much additional code and work it would require, but I could check it in detail
right after your answer according this message. However if we would use Flex framework it would be a lot easier as
there is ScrollBar object which has this functionality.

Based on what we said above, it makes sense not to have the scrollbar in AS. 

I hope my thoughts are a little more clear now. Feel free to ask further questions and I am looking forward to your comments.

Sounds good!

Let me know if you have any question as well.

Thank you!

Regards,
Sebastian Kostuch

Best,

Tiziana

Kind regards,
Sebastian Kostuch

On 18.02.2014 10:23, Tiziana Refice wrote:

(Adding Meredith, to keep her in the loop of the changes to the Flash client).

HI Sebastian,

I reviewed all the pending changes except for FlashIssue114.

I will look into that in the next few days.

Thank you!

Tiziana

On Mon, Feb 17, 2014 at 11:35 AM, Sebastian Kostuch <> wrote:

Hi Tiziana,
thanks a lot for your reviews. Keeping them in mind I have made some fixes in my code.
You can see changes on related branches, also I list them here:
1. FlashIssue113 - set missing variables in clearResults method and changed position of restart button
    (the problem with tabs instead of white spaces I have fixed right afer first commit, it can be viewed here)
2. FlashIssue118 - changed color of active button
3. FlashIssue116 - changed text color and fixed code formatting

Please let me know if everything looks now ok for you.

Regards,
Sebastian Kostuch

On 14.02.2014 11:50, Tiziana Refice wrote:

Done! I reviewed all the changes.

Please let me know if my comments are not clear.

Thanks!

On Thu, Feb 13, 2014 at 11:32 AM, Tiziana Refice <> wrote:

Hi Sebastian,

FYI: I am planning to review all yr changes to the AS code in the next few days. Most likely on Sat.

Cheers,

Tiziana

On Thu, Feb 13, 2014 at 11:16 AM, Sebastian Kostuch <> wrote:

Hi,
recently I have pushed few commits related to flash client:
1. Added possibility to restart test after first completion (FlashIssue113 branch)
2. Active button in result view is now being highlighted (FlashIssue118 branch)
3. Console output is now little more legible (FlashIssue116 branch)

Please feel free to review them. Any comments are welcome and appreciated.

Regards,
Sebastian Kostuch

On 10.02.2014 19:06, Tiziana Refice wrote:

Hi Will,

I will review the patch in the next few days.

Thanks!

On Sat, Feb 8, 2014 at 6:32 PM, Will Hawkins <> wrote:

On Saturday, February 8, 2014 08:44 EST, Tiziana Refice <> wrote:

> On Fri, Feb 7, 2014 at 2:29 PM, Aaron Brown <> wrote:
>
> >  Hey Sebastian,
> >
> >  On Feb 7, 2014, at 9:03 AM, Sebastian Kostuch <>
> >  wrote:
> >
> > Hi,
> > after comparing flash and java clients I have prepared some initial list
> > of suggestions/improvements which could be done to make the flash one
> > better. Please check them and let me know which one are worth/not worth
> > doing. Also if you have something to add feel free to announce it in
> > response :)
> >
> > Flash client improvements:
> > 1. Add some basic options at start page (for example prefered IP protocol,
> > server name)
> >
> >
> >  I'd prefer these options be hidden in an "advanced" button that would pop
> > up a dialog box allowing you to set them. The groal, of sorts, should be to
> > make the default 'view' simple, and with as little jargon as possible.
> > Basically, just a "Start Test" button, and some text like it is now. Also,
> > it'd be great if the text could be set via the HTML so sites could
> > customize it.
> >
>
> About the protocol, I am not sure whether it's possible to select IPv4 or
> IPv6 from within Flash.
> (Flash gives very limited access to the TCP/IP stack).
>
> Just FYI: About the server selection, I will commit shortly a JS snippet to
> automatically select the closest NDT server (among all the NDT servers
> hosted on the M-Lab platform).
>

Hey Tiziana!

I posted a patch to some of the code related to this: https://code.google.com/p/ndt/issues/detail?id=111 I hope that it works. Let me know if you have feedback!

Will

>
> > 2. Add possibility to re-run test after first completion
> >
> >
> >  Seems reasonable.
> >
>
> SGTM
>
> >
> > 3. On Results/Details/Errors/Debug views add appropriated title (or just
> > highlight somehow active button)
> >
> >
> >  It'd probably be good to make it easy for a site to disable the DEBUG
> > button. Also, ERRORS should probably just be merged into results somehow.
> >
> > 4. Maybe add ability to download results as file
> >
> >
> >  You'd probably need to save the results that are already there since you
> > can't re-request results from NDT; it throws them out after its done with
> > the test.
> >
> > 5. Add some basic progress bar during tests (indicating how many tests are
> > completed/left)
> >
> >
> >  That would be good, though it'd probably be good to leave it as a
> > percentage instead of a "number of tests remaining".
> >
>
>
> AFAIK, any UI animation can only be done outside Flash (for example in JS),
> because Flash is single threaded.
>
> >
> > 6. Make some changes in text result presentation (for example errors will
> > be in red color, date will be bolded etc)
> >
> >
> >  Seems reasonable.
> >
>
> SGTM
>
> >
> > These of course are only proposals so feel free to comment
> >
> > Kind regards,
> > Sebastian Kostuch
> >
> >
> Thanks!
>
> >
> >
> >  Cheers,
> > Aaron
> >
> > Come visit the new www.internet2.edu
> >
> >