Affiliation
American Association of Variable Star Observers (AAVSO)
Thu, 12/01/2016 - 01:15

Friends,

 

It is with great pleasure that I would like to introduce our new light curve generator. It was created by one of our volunteers, Mr Francis Hemsher, and was tested by a number of our members (including our council) before becoming available to all. The new tool can be accessed from our “pick a star” (and then “plot a light curve”) front page button. New features include a “box” function that allows zooming in parts of the light curve, interactive selection/de-selection of filters, selection of specific observers’s data points, interactive JD/UT conversion of the axis (under “preferences”) and many more.

 

Also, the new light curve is connected to the “last observations received” feature of our front page – once a point is being added to the AID, one can see it plotted on the star’s light curve!

 

We will be adding new features to this tool as we go, and we will keep you informed on our progress. For now, please check it out J

 

Many thanks to Mr Hemsher and our staff and volunteers involved to create this new tool for our community!

Best wishes – clear skies,

Stella.

Affiliation
American Association of Variable Star Observers (AAVSO)
First blush...

I love the configurability and the inputs being on the same page, but I hope that there will still be some option to produce a light curve with the former eye-pleasing graphic style after playing with the controls.

Affiliation
British Astronomical Association, Variable Star Section (BAA-VSS)
New LCG

I don't like it.  It's awful and looks like a toy.  Can we keep the old one in addition to this please?   The light curves are much better for including in papers, presentations etc. 

Gary

Affiliation
American Association of Variable Star Observers (AAVSO)
?

'Data not found for this star'

I've uploaded nearly 500 data points for this star, but it appears there's now no data for it!
Perhaps we could have the old LCG back until the new one is working?

Affiliation
Vereniging Voor Sterrenkunde, Werkgroep Veranderlijke Sterren (Belgium) (VVS)
2MASS J20060630+2213287

Looks like an URL encoding problem somewhere.  The identifier 2MASS J20060630%2B2213287 (the "+" encoded as %2B) seems to work.

Patrick

Affiliation
Astronomical Society of South Australia (ASSAU)
That makes sense. I checked

That makes sense. I checked that I can access this star in VStar to rule out a back end web service problem.

I have code in VStar that does this:

public StarInfo getStarByName(String name) {
// Replace "+" with %2B (thanks Patrick) and spaces with "+".
return retrieveData(
"ident=" + name.replace("+", "%2B").replace(" ", "+"), name);
}

Easy to forget to do this kind of thing and easy enough for Francis to fix now that we've pointed it out.

David

Affiliation
Astronomical Society of South Australia (ASSAU)
Initial feedback

I know how much work is involved in developing something like this. Settling on a user interface that pleases everyone isn't always a trivial task.

A good first cut. Thanks Francis.

I have some hopefully useful feeback with reference to the attached screenshots from Safari (9.1.3) unless otherwise noted:

  • A Save... button would be good since one cannot right-click on the plot to save an image. I suspect that people are likely to want save more than print.
  • The range should be extended a little more to avoid observtion symbols partly falling outside of the plot area, e.g. see the visual obs near minimum on the supplied plot.
  • The same comment applies to the domain axis (i.e. time).
  • Observations on the plot do not seem to disappear by deselecting bands such as Visual or V until the All checkbox has once been deselected and reselected.
  • With Safari, some additional space is warranted between the time axis labels (JD values) and the section showing contributing observers. I notice that this is NOT a problem with Chrome however.
  • On Chrome, I see the word "BETA" as a watermark on the plot but I do not see this with Safari. This also interrupts tick marks and lines on the plot. See "LCG BETA" attachment.
  • Having access to old and new LCG versions as others have noted makes sense in the early public testing/feedback/BETA stage.

I'll let you know if I have any more feedback.

Keep up the good work.

David

Affiliation
American Association of Variable Star Observers (AAVSO)
Old LCG still available

Hi All,

The old LCG is still available here: https://www.aavso.org/lcg

You can also get to it via the grey menu tabs "Data" > "Data Access" > "Light Curve Generator (LCGv1)"

-Sara

Affiliation
American Association of Variable Star Observers (AAVSO)
I don't wish to offend anyone

I don't wish to offend anyone as I'm sure a lot of hours of effort were put into the redesign, but I regard the new LCG as a major step backward. The best that I can tell trying it this morning is that all former user control pre-plotting options are gone. Individual observers can no longer be highlighted for identification and I have to unselect each class of symbols individually if I'm not interested in seeing them. I'm sure that I'll find more that I dislike, but that was what I noticed in the very first try. As an actual long-time observer, the old manner of presentation was far better and more logical.

J.Bortle   (BRJ) 

Affiliation
American Association of Variable Star Observers (AAVSO)
Thanks for the enhancements

Thanks for the enhancements and the continuing policy to improve the observer tools. 

I really like being able to select preferences, filters, individual's data points, means, error bars, photometry tool used and time domain range on the same page of the graph.  A copy feature would be appreciated.  The photometric red filter selection and the ability to see more of the WebOBs comments would also be helpful.

Thanks again for these tool enhancements

Clear skies

Mike

Affiliation
American Association of Variable Star Observers (AAVSO)
new LCG

I stumbled on this before Stella's annoucement.  At first it was a shock, but the more I play with it the more I like it.  I love the improved configurability (if that's really a word) with the controls in the same window as the chart.  I quickly realized that I could get the chart to show exactly what I wanted much faster with the new tool.  I really like the "box".  

Highlighting in yellow the points from a specific observer is not as clear as the cross in the old LCG, especially when the observations are crowded.   I'd like to see an option to use a cross or the highlight to identify points from the selected observer.

Phil 

Affiliation
American Association of Variable Star Observers (AAVSO)
pluses, a few minuses

I tried several tasks on the new LCG.  I like the BOX option and the flexibility of having various display options at the top of the plot.  The tasks I tried all seemed to work properly with google chrome.  By contrast, the plot did not seem to fit in the display space with a kindle fire tablet running a Silk browser.  However, I note that some of the general AAVSO webpage menu items also haven't worked so well with Silk since the last general webpage update.  So, some definite pluses with the new LCG, but some tasks seem to still run better on the old LCG.  Setting the limit on the number of days plotted seemed easier under the old system.  I also like the way the green V CCD point markers fall on top of the black visual markers in the old plot. The large crosshairs for highlighting a particular observer in the old system are often more readily visible than yellow dots in the new LCG.  I agree with retaining the old LCG option as well as the new for now.

Horace

Affiliation
American Association of Variable Star Observers (AAVSO)
I like the new LCG.

Like many, I was taken aback by the new Light Curve Generator when I first saw it, but after a couple of days I have gotten to like it. It is like the old LCG, with a lot of the features of VStar, without having to download the VStar program. Since I use VStar a lot for my own variable star research, I got the hang of the new LCG pretty quickly. So it works for me, though I agree with others that the big blue crosses used in the old LCG to indicate a particular observer's data are easier to see in a cluttered plot. I even like how colorful the new LCG is!

Affiliation
American Association of Variable Star Observers (AAVSO)
A new look!

Wow - it really does have a fresh new look! The new tools will keep me busy for a while trying them all out! I like that it reminds me of VStar (as others have pointed out). Thanks for all the hard work that went into this!

Kris

Affiliation
American Association of Variable Star Observers (AAVSO)
Thanks

I think this is a great step forward. You have to get used to it, yes, and like every new thing it has bugs, but actually it's a quantum leap IMHO. I'm not sure why one would prefer the old one, becaue the bew one offers so many more features:

The old LCG was just that, it created a plot given some parameters, but you could not interact with the plot once it was drawn because it was essentially just a bitmap. To change it, you needed to go back to the input form and generate a new plot.

The new thing allows you to (personal list of favorites):

  • click on individual datapoints to inspect them, that alone is so useful
  • exclude/include individual observers and compare their contributions by "blinking" their light curves. Also very useful
  • Put label bubbles onto dedictaed datapoints for printouts
  • Reporting discrepant data points directly from the light curve plot. Cool, and could have a significant impact on data quality. 

The rror bars don't seem to work yet, I even had a plot where hidden/deselected data points had garbage stuff plotted as error bars (tiny 'y' characters I think). 

I also think that the plot should either automatically re-scale after changing the selection of bands to display, or have a "redraw/rescale" button to manually trigger a rescaling ( also useful after you desect observers who contributed discrepant data points).

 

CS
HB

 

Affiliation
American Association of Variable Star Observers (AAVSO)
Chrome Browser Preferred

I've been running and testing the new LCG for months. Although It runs in all browsers, it  is so much more smoother and seamless in Chrome. Google has a very substantial team of Chrome browser developers that have moved ahead of the others. If you intend to use the LCG alot, you'll find it a more enjoyable experience with Chrome.

Thanks for your comments so far. Please continue to provide your feedback...it is much appreciated.

- Francis

Affiliation
American Association of Variable Star Observers (AAVSO)
First Experiments

I have spent some time working with LCG2 and my notes are as follows.  I am using a MacBook Pro dual core running OSX 10.9.5 and Safari 9.1.3 (later switching to FireFox 50.0).

1)  It appears that the SS Cyg lightcurve at startup is a canned dataset.  If you explicitly load data for the time range in question, the display is different: new "fainter than" observations appear and the spectra observations disappear.  I don't think it is wise to present something that looks like the results of an actual databse lookup when it is not.

2) It has already been noted that shutting off visual data points does not always work.  Sometimes B, V, and R will also not shut off, while I band can be suppressed.  In the initial display, if All data are turned off, the spectra points are still displayed.

3)  Admittedly, if I plot data for a star, I should know the name of the star.  Nonetheless, I think the star name should be one of the most prominent textual fields, especially if I go to print the curve (more about printing later).  As it is, the name is not particularly visible.  Also, under certain circumstances, the preceding string "AAVSO Light Curve:" will be replaced by the name and version of your browser (attachment lcg_browsername).  The date displayed as part of the star name always seems to reflect the range for which the data were loaded, not the time period of the box.

4) I don't understand why the Civil vs Julian date selections for data load and data display are disconnected.

5) If I attempt to load SS Cyg with a JD range of 0 to today, I am told "No Observations Found"

6)  Say I perform a download using civil dates.  I then try a new download with Julian dates.  The end date is converted to Julian format but the start date is not.  Should you accidentally invoke the lookup with this mix of formats, you get "Database temporarily out of service."

7)  The download function will accept a month of 13.  It will then say "Database temporarily out of service" when the lookup is activated.

8) If I click on a "Print" button, I expect that it will create a print.  On Safari, all I get is a pop-up that tells me I can highlight data (attachment "lcg_printscreen").  The only pop-up option is "cancel."  The instructions regarding landscape+tabloid do not make sense in the OSX environment.  While you are in this print mode, you can annotate points with information pop- ups by clicking.  However, if you merely mouse-over a point, you get a different information pop-up that cannot be deleted, except by mousing over another point (and getting another pop-up), or clicking on said point twice to turn it into a print annotation and then make it go away.

9)  Need for work on error bars has been noted already.  In my print screeen I highlighted three of them.  I do not understand the purpose of the arrows.  They are given as many pixels as the hash lines to which they point, but do not improve readability.  Their size appears to be scaled with the size of the error, which does not make sense to me.  Larger hash marks with no arrows seem more appropriate.

10)  Vertical bars in the lightcurve are sometimes missing (see lcg_printscreen, center)

11)  As I noted in another forum, our data access tools presently have three inconsistent formats for Civil date.  The new LCG introduces a fourth (YYYY/MM/DD).

12)  When using the scroll function with a box, clicking on the arrow moves the green window indicator right away, but the data may not move for some time, and there is no indication that tool is working on it.

13)  On a laptop, the list of bands can exceed the widest screen width (attachment lcg_chcyg).  Also, a mysterious bar appears on the right hand side covering the icons fior the rightmost bands.  If I slide the left edge of the window off the screen and then stretch on the right side, so as to reveal the hidden bands, I find that the display stretches vertically as well as horizontally.

14)  When working with a large dataset, manipulation of the box marker becomes very sluggish.  It may lag for seconds behind the mouse movement.  

15)  Should I accidentally anchor the upper left of the box in the wrong place, I can't get rid of it except by completing the placement and then invoking "reset".

16)  If I load Ch Cyg from 2009/6/17 to 2016/12/03, OCX in the observer list becomes highlighted (attachment lcg_chcyg2).  Why?  I first thought this indicated the most prolific observer, but this not always the case.

17)  There is a large excess of color on the page.  A classic method for conveying graphic information is to use small "spots of intense color" (Edward Tufte).  In the light curve, this is what is done, though I think it is questionable whether the black circles with interior squares and diamonds work well.  But in the observer list, the situation is turned on its head: color is used to highlight non-information.  The big blue border around the list is not needed (no one will mistake the list for part of the light curve).  Within the list, we have two more shades of blue whose only purpose is to distiguish between adjacent lines in the table.  This can be done in much more subtle ways (eg: light grey shades).  Take a step back from your computer and look at the observer list.  The most visually "active" parts of the display are the yellow boxes and the white lines (if you have disabled display of a number of observations, the proliferation of white boxes then revealed will also jump out at you).  This is not good graphic design.

18)  When I loaded T CrB from 2425000 - > now, Safari wedged up and had to be forcibly terminated.

19)  The rolling-up and down of pop-ups is annoying eye candy.

20)  That a large data download takes time is not surprising, but it appears that the greater part of the effort goes not into making the curve, but composing the observer list.

 

After experimenting with Safari, I tried Firefox, where I experienced more severe performance problems, and I started up a cpu monitor.

21)  After the SS Cyg "Welcome" is loaded, I was getting 100% load (on my dual-core machine, that means that one processor's worth of computing power was used up).  I was doing nothing at all.  If I then moved the mouse down into the observer list, the load dropped to ~ 80%.

22) While loading a big rho Cas dataset,  FireFox gave me alerts about the web page slowing the browser.

23)  After the data were fully loaded and the observer list generated, usage went way down, but any time I moved the mouse, it jumped back up into the 100% range.

All this took quite a toll on my laptop battery.  Running the cpu montior with Safari showed less dramatic, but still high loads.

I will close with a question:  is this a "release" version, or a beta test version?

Tom

 

 

 

Affiliation
American Association of Variable Star Observers (AAVSO)
current JD

For visual observing, I commonly used the LCG to give me current JD in the minutes before I peer through the binoculars. I found it handy and reliable. Does the new LCG always come up showing current JD time?

It just now popped up from WEBOBS so I could see the VPHOT data I had just submitted.  Running Saphari on a macbook pro. The display looks just too busy. Can't see the JD numbers on the bottom of the plot because a blue contributors box overwrites it. The Print box does not print, rather it says: 

Print Plot

You may click on symbols to add/remove their data to your print. Move the data values as desired.

cancel
(Set print to Landscape + Tabloid)

Also, the new LCG generator does not remember the last request I made. 

The old LCG comes up in the data selection mode, the new LCG2 comes up in the data display mode.

boundrys for the box tool seemed to be defined by data in the selected box rather than the area selected on the main plot.

I am sure that the new LCG will get better, but I'll vote for the old LCG for now.

Ray

Affiliation
American Association of Variable Star Observers (AAVSO)
Highlighted Observer Modification

Hi All,

A modification has just been made to the way the highlighted observer(s) are displayed. Rather than the subtle yellow highlight around each data point, there is now a sort of orange cross being used which makes the points more obvious.

Just click the orange box to the left of an observer's initials to see how this now looks.

Please keep the comments coming. We intend to go through them soon and prioritize those that need attention.

Thanks,
Sara

Affiliation
American Association of Variable Star Observers (AAVSO)
plot contributors

checking a couple of fields, I notice that my data is showing up in the mouse-clicked observation window as from obscode "H" rather than "HQA".  Additionally, on V5668 Sgr at least, observer "H" doesn't even show up in the "contributors to the plot" list, even though there are a few hundred observations from me.

In general, a nice improvement from the original light curve generator, and with the potential of handling many new aspects, such as external databases and additional filters like Sloan.

Arne

Affiliation
American Association of Variable Star Observers (AAVSO)
Comment Field

I noticed that my comments are not shown in the data point drop down.  Here is a typical comment, 12" 1603ME2x2 TBV=1.061 0.02  TV_BV=0.022 0.007  TB_BV=0.060 0.021 and here is what is seen, 12. Are there character limitations different in the new tool?

Thanks,

Mike

Affiliation
American Association of Variable Star Observers (AAVSO)
Quote mark in a comment

Hi Mike,

It seems that a quotation mark in the comment body was causing the data following the comment to be dropped.

Sara Beck is replacing a few files in the new LCG  to fix this. Your comments will then display OK

- Francis

Affiliation
American Association of Variable Star Observers (AAVSO)
Quote mark in comment field

I just uploaded the files Francis sent me. Please give it another try Mike, and let us know if it works now.

Thanks,
Sara

Affiliation
American Association of Variable Star Observers (AAVSO)
I've simply removed the

I've simply removed the quotation marks and it worked great.  I will try a report with them back in just to see if it now works with them present

Thanks

Mike 

Affiliation
American Association of Variable Star Observers (AAVSO)
New Feature: Simultaneous Mean Curves - Is this needed?

Hi All,

Sara Beck (the fairy godmother for the new LCG) and I have been discussing the possibility of providing the ability to display simultaneous mean curves.

Basically this would use the current check boxes adjacent to each symbol rather than the drop-down menu to choose the band mean. This drop-down selection allows for only a single band mean curve to be shown. The checkbox selection would then provide the ability for you check/uncheck any symbol to show/hide its mean curve, displaying as many curves as needed.

The question is: 

Would you have any need to view means of various bands simultaneously?

 

Let us know,

Thanks,

Francis

Affiliation
American Association of Variable Star Observers (AAVSO)
I see that the LCGv2 from the

I see that the LCGv2 from the home page complains just like LCGv1 used to do if no variable star is entered. That was always annoying.

Now there is a way around it;

Click LCG on the front page for no response. browser back-arrow. Click LCGv2 on the data-> data access drop-down menues, again no response, browser back-arrow. Click LCGv1. it remembers your last request and displays the request page. After that, you get SS Cyg from the data menues or from the front page without typing in a star name.

RayTRE

I claim to be the worst programmer on the planet

Affiliation
American Association of Variable Star Observers (AAVSO)
remember prior requests; star entry font

The old LCG remembered previous requests and popped up a list when I started typing in the star name.  Version 2 doesn't seem to do this.  Can this memory of prior star requests be add to the new version?

For my system (Mac OSX + Firefox 49.0) the font for entering the star name is too large for the entry box.  Eight characters fill the box.  When I type in something like "IRAS 04519+3553" I have to scroll back and forth in the entry box to be sure  it's all there and typed correctly.  Can the entry box be made larger, and the font smaller?  Perhaps there could be a "preference" setting for the font size.

Phil

Affiliation
American Association of Variable Star Observers (AAVSO)
Star Entry Font

Hi Phil,

Yes, I can see what you mean.

I changed the font size: Now about 18 characters will display. This should be online tomorrow A.M.

As to the 'remember prior requests': This would require a substantial cookie package. Maybe if others feel the same, I'll consider it...

- Francis

Affiliation
American Association of Variable Star Observers (AAVSO)
Upper/lower case b Persei

Hi, The New LCG shows marked improvement in power.  However, when inputting a star name, the star "b Persei" (not Beta Persei) has an unfortunate name to distinguish from "beta Persei".  When we type "b Persei" or "b Per" the software immediately changes to "B PER", but plots the data for b Persei.  We have just started a new campaign to observe the upcoming eclipse of b Persei.

Thanks,

Don

Affiliation
American Association of Variable Star Observers (AAVSO)
remember prior requests clarification

When accessing the new LCG from the VSP box on the AAVSO home page, prior star requests are remembered and listed.  It's the "star name" box in the version 2 display itself that doesn't remember prior requests.

If this is too much hassle to put into the new LCG itself, it would be great if that "memory" capability could be retained in the access from the VSP  box on the front page.

Phil

Affiliation
American Association of Variable Star Observers (AAVSO)
Add to Preferences: Remember This Star

It seems that you are interested in a specific star's observations and band set. Therefore I am considering providing the ability to to allow you to choose a star and a timeline to automatically call when you next return to the LCG  via the direct URL:

https://www.aavso.org/LCGv2/ 

if you check this preference, it would set a cookie on your computer.

This would  would then display your selected bands on the remembered star along with its previous timeline span, readjusted backward from the current time.

(This feature assumes that you are tracking current observations.)

Let me know.

Francis

Affiliation
American Association of Variable Star Observers (AAVSO)
remembering star names

Francis,

What you described would be good, but I had something slightly different in mind.

I usually have four or five stars in my observing list that I like to check regularly with the LCG.  (I'm sure many observers have a lot more.)  My targets have names like V1405 Cyg, or V0742 Lyr, or NSVS 1461135, or NSVS J0051273+645649, and soon IRAS  04519+13553 will be observable at a decent hour.

With LCGv1, when I start entering a star name that starts with "N" a drop down list appears with all the star names I have previously entered that start with "N".  I can select that name from the drop down list and avoid typing in a 16 or 20 character name.  Likewise for names starting with "V", or "I", etc.

Remembering the selected filters, time spans, etc. would be nice but less important because it's so quick and easy to configure the plot from LCGv2 once the star is brought up.  The problem for me is just typing in those long names.

Since the access to LCGv2 via the VSP box on the AAVSO home page has this feature already, maybe a simple solution for my problem would just be a "Back to VSP" option from the LCGv2 display that links back to that VSP box on the home page.  If you could do the same thing (just remember the names) from the "Plot Another Curve" box  within LCGv2 that would great.  The other preferences (filter band, dates, etc.) would be gravy, but less important for me.

BTW, thanks for changing the "Star Name" box to the smaller font.  Perhaps you could do the same for the "From Date" and "To Date" fonts.  Now, when Calender Date is selected the full date doesn't fit in the box.

Phil

 

 

Affiliation
American Association of Variable Star Observers (AAVSO)
List Of Star History

Hi Phil,

Sara and I are evaluating this and would like to know your thoughts before inplementation. (Note: We also providing the ability for users to preselect their bands, rather than displaying all bands)

Whenever a user requests a star, the following is stored in a cookie:

1) Star Name

2) Time Stamp

3) User ID

4) JD time span

5) Date format

6) Preferred Bands

 

A drop down menu is displayed at the 'Plot a light curve' and 'Plot Another Curve' panes as shown below with the list of previous stars in alphabetical order:

Inline image 1

 If the user chooses to select a star name from the drop down menu the following occurs:

a.) Its name will be written in the 'Star Name'  text area.

b.) It will choose the Date Format previously used when the star was last called.

c.) The  From Date will use the JD time span from the cookie(the user's previous timeline when this star was last called) . The To Date will be the current time.

d.) If the user had  previously selected a specific set of bands for this star, the bands selection check boxes will display with the previous band set checked. (the user can modify those selections)

 

After the user selects this star, its cookie is updated with the current values.

The 'Clear History...' selection removes all cookies and starts over, with new cookies created when the user selects stars in the future.

 

Note: a cookie is also set when the user requests "Most Recent" or includes a star name in the 'Plot a light curve' from the AAVSO main page.

Affiliation
American Association of Variable Star Observers (AAVSO)
List Of Star History

Francis,

I couldn't view the image in your post, but from your description that all sounds really good to me.  Perhaps you could send me the image via the "contact" email link in my profile .

Thank you very much for addressing my request.  

Phil   SPP 

Affiliation
American Association of Variable Star Observers (AAVSO)
Second Experiments

After additional time with LCG2, I have more to report.

1)  Under Firefox, I neglected to note another high-cpu scenario that did not make sense.  If you enter the dialogue to load a new star and then click in one of the date fields as though to enter a number, cpu utilization will shoot up even as you let the machine sit there, doing nothing.  This does not happen in Safari (the earlier-described Firefox high load after SS Cyg startup also does not happen in Safari).

2) When the mouse is dragged through the light curve region, LCG2 looks for stars to temporarily highlight by enlarging the symbol under the arrow.  With large datasets, this process becomes computationally expensive.  With roughly 12,000 observations from Betelgeuse, dragging the mouse through an empty region of the curve send cpu utilization to as much as 80%.  When dragged through actual data points, usage grows to 130%.  If I trim the dataset to about 5,000 points, dragging through empty space only consumes about 50%, but through data is still 130%.  If I further whittle down to about 1500 points, peak usage drops to 30% in empty space, but still pegs out at 130% among data points.  From this I conclude that the actual process of highlighting data points is very cpu-intensive and should be examined.  I think it is also worthwhile to ask if the code that checks for "mouse-over" of data points can be made more efficient.  Is it really worth using all of the those cpu cycles for highlighting?  We should not assume that processor (and battery) resources are ours to dispose of casually.  The scenarios, above, were observed under Safari.  Interestingly, while Firefox also incurred high loads, they were substantially lower (eg: peak utilization during mouse-over of actual points only got up to 100%).

3)  It appears that the JD->Civil date conversion bug I noticed has been fixed.  But I now see that whenever a switch is made between calendars, the date range is automatically set to a two-year window ending on the present day.  I think that if the fields for either the start or end contain valid dates, they should be converted to the new calendar, not reset.

4)  The Civil date input now rejects months greater than 12, but it still accepts day-of-month in excess of the true allotment.

5)  Under Firefox, when creating a box at the far right of the curve region, it is not possible to anchor the lower-right corner of the box (attachment lcg_ffwindow) - the click is ignored.  The example shows a case where the box extends beyond the curve region, but the same problem occurs just inside the right-hand edge.  This was Betelgeuse, again.

6)  I suggest that the arrows for extending the timeline should be deactivated when no more data are available in the given direction.  On the right-hand side, at least, the arrow could be turned off when we are at the current day.

7)  I suggest that the amount of time added by an extension click be proportional, in some way, to the time span of the curve already displayed.  With long duration curves, the extend operation seems to be appending very small time intervals.

8)  Regarding per-observer highlighting, I would entirely dispose of the formerly-yellow-now-orange boxes and make the observer code boxes directly clickable.  This would recover screen space taht is largely wasted.

9) If I disable a specific observer and then re-enable him, his code appears to the right of the curve region.  This makes sense if I am disabling all observers and then enabling a few, but if I am looking to see what the full curve looks like without a few observers, I don't want those codes to come up when I put the observers back.  If I have not disabled all observers, I suggest suppressing those codes.

10)  This software was not distributed with any release notes to explain the functionality it provides, and whether any parts are known to not be working yet.  This is a major omission.  For instance, does differential data plotting work?  I tried such a plot for Betelgeuse (attachment lcg_diffA).  I got a blank curve, and afterwards, could not load any more data (attachment lcg_diffB) and had to restart LCG2.

11)  In my previous post, I noted situations where an unexplained bar appeared above the curve region on the right, sometimes covering part of the symbol legend.  This appears to be a truncated "last observation" pop-up.

12)  Why are error bars not shown in the same color as the data point?  Same-color bars would make it easier to associate the error with the right datum and free up the color purple for use in a band symbol.

13)  In further regard to symbols, LCG2 is already struggling to differentiate, visually, among the bands it supports.  What happens when we add Sloan bands and who knows what else?  We need to think about whether it really makes sense to display, by default, all bands.

14)  In the preferences dialog, it is possible to set a minimum/maximum magnitude pair with the minimum greater than the maximum.

15)  If I edit the min/max values but do not put the change into effect, I cannot reset them to their original values.  The reset button should always work.

16)  Returning to functionality offered that may not be working, does the APASS option really do something?  If I load the last two years of Betelgeuse and then go to the Preferences dialog, I can select the APASS option.  But if I load Betelegeuse back to JD 2455000 and go to Preferences, I am not able to select APASS, which does not make sense.

17)  If a data point has been highlighted and I mouse over it, it does not expand as it does when not highlighted.

18)  We should consider an option to sort the observer list by observation count rather than observer code.  If I am trying to see which observers are making the biggest impact on the curve, I must presently scan throught whole list.

19)  The print "dialogue" text has been changed to say "Save to PDF" on OSX.  However, the save function is actually "Export to PDF."  Furthermore, this operation is only accessible via a drop-down menu, which means the mouse must be moved out of the LCG2 window to invoke it.  If the mouse arrow was in the curve area to annotate some points for printing, the action of moving the arrow to the menu at the top of the screen is highly likely to mouse-over a data point causing an information bubble to appear.  I know this bubble does not appear on the saved PDF, but it is still highly annoying.

20)  Regarding PDFs, users are likely to want to make curves for papers to appear in JAAVSO.  We should be sure that LCG2 outputs conform, or have an option to conform, to the JAAVSO style guide for figures.  The printed version of JAAVSO is rendered in monochrome, and colored dots do not necessarily convert well to monochrome.  Likewise, the more "fiddly" LCG2 symbols used for TG, TB, etc., may not reproduce well.

 

The following concern operations regarding mean series'.

21)  What is the intended compatibility between boxes and means?  If I place a box in my dataset, I can no longer create a mean series.  But if I create a mean series, I can then place a box.  There are odd things that can then occur, but I'm not sure if those are bugs, or if it was a bug to let me make the box in the mean series.

22)  If a bin value is typed in, the slider button does not move to match it.

23)  The slider button starts all the way to the left, with a bin value of 1 day displayed.  But if you move the button to the right, then back all the way left, you get a bin of 0.1.

24)  If the print "dialog" is activated in the mean display, the dialogue is partially obscured by the slider.

25)  Mean curves sometimes go outside the plot boudarries (attachment lcg_meanA).

26)  In a mean series, the mean "points" cannot be annotated for printing.  An information bubble appears upon mouse-over, but you cannot click to make it a print annotation.

27) The mean series display will let me select a band for which the data have been suppressed.

28) Do the smooth curves serve any scientific purpose?  Since we do not describe what these options are actually doing, mathematically, I am dubious.  Furthermore, they are subject to anomalies.  In "smoother," physically impossible curves (sections going backwards in time) can appear.  I have also seen a case where the curve went off-center through a symbol, then doubled back to strike dead-on (attachment lcg_meanB: see points on either side of large gap in middle-right).  In the "smoothest" case, the curve will not even go through all the mean points.  I would regard the mean points as a constraint specified by the user, but the smoothest curve ignores that constraint.

At this point, there is a more general issue I want to raise regarding consistency among AAVSO user tools.  I have already noted the appearance of a fourth Civil date format in LCG2, but the considerations go further.  All AAVSO tools ought, in my opinion, to use the same procedures for the same function (such as creating a box) and use a common graphical "vocabulary" for displaying the same kinds of data.  But the LCG2 box placement protocol is different from the VStar protocol, and I keep finding myself trying to make an LCG2 box using the VStar sequence of mouse operations.  And LCG2 uses symbology for data points that is different from VStar.  Were these conscious choices?  

VStar does not, by default, throw up all bands found in a data set.  This has the advantage that it does not need to use a full complement of band symbols unless the user actually needs to display everything.  If, for example, I load LCG2 with a dataset having dim U and bright H data, but I want to make a mean of say, B, in between, I have a problem.  The vertical scale of the curve display will always stretch out to encompass the U and H data, even when I turn off those bands, meaning my mean B curve will have a bunch of blank space above and below the line.  If I first use a box to first exclude the U and H data, I am then unable to make a mean series (I am presuming here that box-after-mean capability I found is not intended to work).  Why am I forced to manage data that I don't want to see in the first place?

Going forward, another question to be asked is where do we place the line between LCG2 and VStar (or any other pair of future tools)?  They already have overlapping features, where does that end?

Tom

 

Affiliation
American Association of Variable Star Observers (AAVSO)
Thanks, Tom!

Hi Tom,

Below is listed the items from your two experiments posted in the forum, along with some comments I've added. Thanks so much for identifying about a dozen glitches that we would have had to address sooner or later. Because it is sooner, you've helped improve the LCG experience for all viewers. Your suggestions will included in the next update, about Jan 6th.

Please note that some of the items, if they are caused in the Safari browser, are difficult for me to validate. I have a Windows 10 OS, and Safari does not support a Windows version. I do have an emulator program for Safari, but it does not have the true browser response for many of the features in the LCG.

Since you can run both Chrome (the preferred browser for the LCG)  and Safari in your MacBook I would surely appreciate your help in identifying any problems specific to Safari.

First Experiments

I have spent some time working with LCG2 and my notes are as follows.  I am using a MacBook Pro dual core running OSX 10.9.5 and Safari 9.1.3 (later switching to FireFox 50.0).

1)  It appears that the SS Cyg lightcurve at startup is a canned dataset.  If you explicitly load data for the time range in question, the display is different: new "fainter than" observations appear and the spectra observations disappear.  I don't think it is wise to present something that looks like the results of an actual databse lookup when it is not.

This was used during testing and has been removed.

2) It has already been noted that shutting off visual data points does not always work.  Sometimes B, V, and R will also not shut off, while I band can be suppressed.  In the initial display, if All data are turned off, the spectra points are still displayed.

I can't duplicate this problem. (The Spectra points were shown for example purposes only in the test star and will be displayed in the future when Spectra data is available)

3)  Admittedly, if I plot data for a star, I should know the name of the star.  Nonetheless, I think the star name should be one of the most prominent textual fields, especially if I go to print the curve (more about printing later).  As it is, the name is not particularly visible.  Also, under certain circumstances, the preceding string "AAVSO Light Curve:" will be replaced by the name and version of your browser (attachment lcg_browsername).  The date displayed as part of the star name always seems to reflect the range for which the data were loaded, not the time period of the box.

The Browser/Version is no longer displayed. The real estate for the top 'bar' is limited and cannot take a larger font for the star name. The timeline (range)  of the data will remain as the user requested. Changing it may be confusing.

4) I don't understand why the Civil vs Julian date selections for data load and data display are disconnected.

When a user selects a star and its date format, the LCG does display with the requested format in the x-axis. Under 'Preferences', they may switch back/forth between either date format. Does not this happen in your LCG display?

5) If I attempt to load SS Cyg with a JD range of 0 to today, I am told "No Observations Found"

Thanks, this has been fixed

6)  Say I perform a download using civil dates.  I then try a new download with Julian dates.  The end date is converted to Julian format but the start date is not.  Should you accidentally invoke the lookup with this mix of formats, you get "Database temporarily out of service."

Thanks, this has been fixed.

7)  The download function will accept a month of 13.  It will then say "Database temporarily out of service" when the lookup is activated.

OK, this has been fixed.

8) If I click on a "Print" button, I expect that it will create a print.  On Safari, all I get is a pop-up that tells me I can highlight data (attachment "lcg_printscreen").  The only pop-up option is "cancel."  The instructions regarding landscape+tabloid do not make sense in the OSX environment.  While you are in this print mode, you can annotate points with information pop- ups by clicking.  However, if you merely mouse-over a point, you get a different information pop-up that cannot be deleted, except by mousing over another point (and getting another pop-up), or clicking on said point twice to turn it into a print annotation and then make it go away.

We've attempted to clarify that.

9)  Need for work on error bars has been noted already.  In my print screeen I highlighted three of them.  I do not understand the purpose of the arrows.  They are given as many pixels as the hash lines to which they point, but do not improve readability.  Their size appears to be scaled with the size of the error, which does not make sense to me.  Larger hash marks with no arrows seem more appropriate.

Arrows indicate +/- span. The length of the error bar is related to its error value. e.g. An error of .01 should not be be shown graphically the same size as 0.5.

10)  Vertical bars in the lightcurve are sometimes missing (see lcg_printscreen, center)

Thanks, this was fixed.

11)  As I noted in another forum, our data access tools presently have three inconsistent formats for Civil date.  The new LCG introduces a fourth (YYYY/MM/DD).

The inconsistency is noted. I think the reason we chose YYYY/MM/DD is because that is what WebObs uses on its individual file upload forms. Which format do you think it should use instead? WebObs Search uses YYYY-MM-DD. The Visual and Extended file format as well as the old LCG use MM/DD/YYYY (which is a bit less intuitive for non-Americans). What is the fourth format?

12)  When using the scroll function with a box, clicking on the arrow moves the green window indicator right away, but the data may not move for some time, and there is no indication that tool is working on it.

This works OK for me(Chrome) in data points less than 10,000. I'm hoping users learn that a ton of data points is tedious, impacting the smooth interactive performance of the LCG.

13)  On a laptop, the list of bands can exceed the widest screen width (attachment lcg_chcyg).  Also, a mysterious bar appears on the right hand side covering the icons fior the rightmost bands.  If I slide the left edge of the window off the screen and then stretch on the right side, so as to reveal the hidden bands, I find that the display stretches vertically as well as horizontally.

This is Safari problem we will eventually fix.

14)  When working with a large dataset, manipulation of the box marker becomes very sluggish.  It may lag for seconds behind the mouse movement. 

The Chrome browser works nicely up to about 10,000 points. Safari and Firefox seem to be sluggish above 2000 points. This confirms Chome's more efficient graphics handling.

15)  Should I accidentally anchor the upper left of the box in the wrong place, I can't get rid of it except by completing the placement and then invoking "reset".

You should be able to drag the Box following its initial plant point. Also, if you want to close it before you resize and run it, you can toggle the 'Box' button to clear it.

16)  If I load Ch Cyg from 2009/6/17 to 2016/12/03, OCX in the observer list becomes highlighted (attachment lcg_chcyg2).  Why?  I first thought this indicated the most prolific observer, but this not always the case.

This intended to show the last observation in the requested timeline.

17)  There is a large excess of color on the page.  A classic method for conveying graphic information is to use small "spots of intense color" (Edward Tufte).  In the light curve, this is what is done, though I think it is questionable whether the black circles with interior squares and diamonds work well.  But in the observer list, the situation is turned on its head: color is used to highlight non-information.  The big blue border around the list is not needed (no one will mistake the list for part of the light curve).  Within the list, we have two more shades of blue whose only purpose is to distiguish between adjacent lines in the table.  This can be done in much more subtle ways (eg: light grey shades).  Take a step back from your computer and look at the observer list.  The most visually "active" parts of the display are the yellow boxes and the white lines (if you have disabled display of a number of observations, the proliferation of white boxes then revealed will also jump out at you).  This is not good graphic design.

Acknowledging contributors is an important feature in the LCG. Relegating them to shades of grey, as employed in the old LCG, was not consistent with our goal. Yes, I may be able to mute them, but choose not to do so.

18)  When I loaded T CrB from 2425000 - > now, Safari wedged up and had to be forcibly terminated.

That's about 125,000 data points. I think they would have eventually loaded (This depends on current demand at the server). I tried this in Chrome, and it took about a minute before the data was displayed.

19)  The rolling-up and down of pop-ups is annoying eye candy.

Typically when a user makes a selection that adds content to the web page, there should be a transitional feedback, rather than 'popping' the content on the page (in case the viewer happens to blink) . This assists them in seeing what was added when a web page has a lot to view.

20)  That a large data download takes time is not surprising, but it appears that the greater part of the effort goes not into making the curve, but composing the observer list.

The observer list is created following the rendering of the light curve and its symbols. This does not typically interfere with LCG plot display.

 After experimenting with Safari, I tried Firefox, where I experienced more severe performance problems, and I started up a cpu monitor.

Hopefully we can somewhat improve this. But, as I've stated in the forum, Chrome is the preferred browser.

21)  After the SS Cyg "Welcome" is loaded, I was getting 100% load (on my dual-core machine, that means that one processor's worth of computing power was used up).  I was doing nothing at all.  If I then moved the mouse down into the observer list, the load dropped to ~ 80%.

I've attempted to fix this..awaiting further test results

22) While loading a big rho Cas dataset,  FireFox gave me alerts about the web page slowing the browser.

Ditto 21)

23)  After the data were fully loaded and the observer list generated, usage went way down, but any time I moved the mouse, it jumped back up into the 100% range.

Ditto 21)

All this took quite a toll on my laptop battery.  Running the cpu montior with Safari showed less dramatic, but still high loads.

Ditto 21)

I will close with a question:  is this a "release" version, or a beta test version?

There is a large 'BETA' image in background. I assume Safari is not rendering it.

Second Experiments

After additional time with LCG2, I have more to report.

1)  Under Firefox, I neglected to note another high-cpu scenario that did not make sense.  If you enter the dialogue to load a new star and then click in one of the date fields as though to enter a number, cpu utilization will shoot up even as you let the machine sit there, doing nothing.  This does not happen in Safari (the earlier-described Firefox high load after SS Cyg startup also does not happen in Safari).

I also am befuddled why Firefox reacts this way.

2) When the mouse is dragged through the light curve region, LCG2 looks for stars to temporarily highlight by enlarging the symbol under the arrow.  With large datasets, this process becomes computationally expensive.  With roughly 12,000 observations from Betelgeuse, dragging the mouse through an empty region of the curve send cpu utilization to as much as 80%.  When dragged through actual data points, usage grows to 130%.  If I trim the dataset to about 5,000 points, dragging through empty space only consumes about 50%, but through data is still 130%.  If I further whittle down to about 1500 points, peak usage drops to 30% in empty space, but still pegs out at 130% among data points.  From this I conclude that the actual process of highlighting data points is very cpu-intensive and should be examined.  I think it is also worthwhile to ask if the code that checks for "mouse-over" of data points can be made more efficient.  Is it really worth using all of the those cpu cycles for highlighting?  We should not assume that processor (and battery) resources are ours to dispose of casually.  The scenarios, above, were observed under Safari.  Interestingly, while Firefox also incurred high loads, they were substantially lower (eg: peak utilization during mouse-over of actual points only got up to 100%).

I did change the 'mouse-move' to improve its efficiency. The 'mouse-over' also should be less cpu-intensive.

3)  It appears that the JD->Civil date conversion bug I noticed has been fixed.  But I now see that whenever a switch is made between calendars, the date range is automatically set to a two-year window ending on the present day.  I think that if the fields for either the start or end contain valid dates, they should be converted to the new calendar, not reset.

Thanks, I fixed this.

4)  The Civil date input now rejects months greater than 12, but it still accepts day-of-month in excess of the true allotment.

Yes, this was fixed

5)  Under Firefox, when creating a box at the far right of the curve region, it is not possible to anchor the lower-right corner of the box (attachment lcg_ffwindow) - the click is ignored.  The example shows a case where the box extends beyond the curve region, but the same problem occurs just inside the right-hand edge.  This was Betelgeuse, again.

I tried this with Firefox and it worked OK for me. 

6)  I suggest that the arrows for extending the timeline should be deactivated when no more data are available in the given direction.  On the right-hand side, at least, the arrow could be turned off when we are at the current day.

Sara and I are considering removing this feature. Let us know if you would like to retain it See:https://www.aavso.org/comment/reply/62905/52362

7)  I suggest that the amount of time added by an extension click be proportional, in some way, to the time span of the curve already displayed.  With long duration curves, the extend operation seems to be appending very small time intervals.

Ditto 6)

8)  Regarding per-observer highlighting, I would entirely dispose of the formerly-yellow-now-orange boxes and make the observer code boxes directly clickable.  This would recover screen space taht is largely wasted.

Users are intuitively more likely to click a check box than the code.

9) If I disable a specific observer and then re-enable him, his code appears to the right of the curve region.  This makes sense if I am disabling all observers and then enabling a few, but if I am looking to see what the full curve looks like without a few observers, I don't want those codes to come up when I put the observers back.  If I have not disabled all observers, I suggest suppressing those codes.

Good idea, I changed as you suggested.

10)  This software was not distributed with any release notes to explain the functionality it provides, and whether any parts are known to not be working yet.  This is a major omission.  For instance, does differential data plotting work?  I tried such a plot for Betelgeuse (attachment lcg_diffA).  I got a blank curve, and afterwards, could not load any more data (attachment lcg_diffB) and had to restart LCG2.

I've run this and get a message "No Observations Found", with no adverse effects. Note: A plot will not display if only one data point is found.

11)  In my previous post, I noted situations where an unexplained bar appeared above the curve region on the right, sometimes covering part of the symbol legend.  This appears to be a truncated "last observation" pop-up.

Yes, I'll fixed that, thanks.

12)  Why are error bars not shown in the same color as the data point?  Same-color bars would make it easier to associate the error with the right datum and free up the color purple for use in a band symbol.

The error bars should be a standard color, and purple seemed a good choice.

13)  In further regard to symbols, LCG2 is already struggling to differentiate, visually, among the bands it supports.  What happens when we add Sloan bands and who knows what else?  We need to think about whether it really makes sense to display, by default, all bands.

We're OK in this regard at this time with good differentiation. I have over a hundred additional symbols if needed.

14)  In the preferences dialog, it is possible to set a minimum/maximum magnitude pair with the minimum greater than the maximum.

OK, this was fixed

15)  If I edit the min/max values but do not put the change into effect, I cannot reset them to their original values.  The reset button should always work.

Good idea, changed

16)  Returning to functionality offered that may not be working, does the APASS option really do something?  If I load the last two years of Betelgeuse and then go to the Preferences dialog, I can select the APASS option.  But if I load Betelegeuse back to JD 2455000 and go to Preferences, I am not able to select APASS, which does not make sense.

OOPS, the Apass checkbox should be disabled (We're awaiting some data format  changes from the database host)

17)  If a data point has been highlighted and I mouse over it, it does not expand as it does when not highlighted.

This works OK for me.

18)  We should consider an option to sort the observer list by observation count rather than observer code.  If I am trying to see which observers are making the biggest impact on the curve, I must presently scan throught whole list.

Good Idea. I added this.

19)  The print "dialogue" text has been changed to say "Save to PDF" on OSX.  However, the save function is actually "Export to PDF."  Furthermore, this operation is only accessible via a drop-down menu, which means the mouse must be moved out of the LCG2 window to invoke it.  If the mouse arrow was in the curve area to annotate some points for printing, the action of moving the arrow to the menu at the top of the screen is highly likely to mouse-over a data point causing an information bubble to appear.  I know this bubble does not appear on the saved PDF, but it is still highly annoying.

I added a click function on the moused-over data bubble to allow the user to click on it to hide it.

20)  Regarding PDFs, users are likely to want to make curves for papers to appear in JAAVSO.  We should be sure that LCG2 outputs conform, or have an option to conform, to the JAAVSO style guide for figures.  The printed version of JAAVSO is rendered in monochrome, and colored dots do not necessarily convert well to monochrome.  Likewise, the more "fiddly" LCG2 symbols used for TG, TB, etc., may not reproduce well.

It's been suggested to JAAVSO to run the print/PDF (In the Chrome Browser) to determine if specific requirements for their Journal are required. If need be, the LCG could include a 'JAAVSO format' checkbox for the print layout.

The following concern operations regarding mean series'.

21)  What is the intended compatibility between boxes and means?  If I place a box in my dataset, I can no longer create a mean series.  But if I create a mean series, I can then place a box.  There are odd things that can then occur, but I'm not sure if those are bugs, or if it was a bug to let me make the box in the mean series.

That's the way it is intended.

22)  If a bin value is typed in, the slider button does not move to match it.

A value change at the slider immediately causes a mean curve to be drawn. Typing data into it would 'bounce' the curve's display.

23)  The slider button starts all the way to the left, with a bin value of 1 day displayed.  But if you move the button to the right, then back all the way left, you get a bin of 0.1.

It is typical that most users would a bin value greater than 1. However, on rare occasions they may want a smaller value.

24)  If the print "dialog" is activated in the mean display, the dialogue is partially obscured by the slider.

Thanks, I fixed this.

25)  Mean curves sometimes go outside the plot boudarries (attachment lcg_meanA).

This is caused by the size of 'clip-path' that hides things outside of its boundaries. Padding was added to prevent hiding a symbol that appeared near the axis.

26)  In a mean series, the mean "points" cannot be annotated for printing.  An information bubble appears upon mouse-over, but you cannot click to make it a print annotation.

Good idea. I may add this in the future.

27) The mean series display will let me select a band for which the data have been suppressed.

I don't see that as a problem.

28) Do the smooth curves serve any scientific purpose?  Since we do not describe what these options are actually doing, mathematically, I am dubious.  Furthermore, they are subject to anomalies.  In "smoother," physically impossible curves (sections going backwards in time) can appear.  I have also seen a case where the curve went off-center through a symbol, then doubled back to strike dead-on (attachment lcg_meanB: see points on either side of large gap in middle-right).  In the "smoothest" case, the curve will not even go through all the mean points.  I would regard the mean points as a constraint specified by the user, but the smoothest curve ignores that constraint.

Default selection is a linear curve. The 'smooth' is available for those interested in trends.

At this point, there is a more general issue I want to raise regarding consistency among AAVSO user tools.  I have already noted the appearance of a fourth Civil date format in LCG2, but the considerations go further.  All AAVSO tools ought, in my opinion, to use the same procedures for the same function (such as creating a box) and use a common graphical "vocabulary" for displaying the same kinds of data.  But the LCG2 box placement protocol is different from the VStar protocol, and I keep finding myself trying to make an LCG2 box using the VStar sequence of mouse operations.  And LCG2 uses symbology for data points that is different from VStar.  Were these conscious choices?  

The LCG provided features that work in a dynamic web application. Trying to shoe horn Java-based applications would have made it less seamless for the user.

VStar does not, by default, throw up all bands found in a data set.  This has the advantage that it does not need to use a full complement of band symbols unless the user actually needs to display everything.  If, for example, I load LCG2 with a dataset having dim U and bright H data, but I want to make a mean of say, B, in between, I have a problem.  The vertical scale of the curve display will always stretch out to encompass the U and H data, even when I turn off those bands, meaning my mean B curve will have a bunch of blank space above and below the line.  If I first use a box to first exclude the U and H data, I am then unable to make a mean series (I am presuming here that box-after-mean capability I found is not intended to work).  Why am I forced to manage data that I don't want to see in the first place?

Yes, we've added the feature that allows the user to choose the bands prior to calling the star.

Going forward, another question to be asked is where do we place the line between LCG2 and VStar (or any other pair of future tools)?  They already have overlapping features, where does that end?

Sara points out:

 That VStar and the LCG are very different tools with different uses. The LCG is for making quick plots via the website to get a sense of what a star is doing and how your own observations fit in. VStar is for data analysis. Being a Java Web Start app, it takes a little more effort to use and some people have trouble configuring their computers to use it. VStar is also loaded with tools for things like period analysis, scripting and loading all sorts of data sets. There are a bunch of plugins available and someone who knows a bit of Java can write their own.

You are right, we have no overall plan and it would be good if you want to work with Stella and the other Council members to develop one.

Affiliation
American Association of Variable Star Observers (AAVSO)
LCG2 on Android

There seems to be significant work to do for it's use with Android devices. The "Preferences" bar contains nothing else and cuts the band symbols in half. The band symbols do not have any info associated with them unlike the laptop version of LCG2.

Was this ever intended to work on Android devices?

Nigel Wakefield

WNBA

Affiliation
American Association of Variable Star Observers (AAVSO)
LCG2 is better for me

Well, I was pleasantly surprised to find out it works better for me than the old one. Its clearly quite a different look and interface, but it didn't take me too long to get used to using it. I have not used a lot of its features, but the major improvements I immediately like are: (The good)

1. Its really great to be able to select individual observations. The popup box gives all the info at a glance. No way to do that with the old version.

2. Also great, you can now quickly select and unselect any particular observers observations.

3. Being able to go and change which star and date ranges you want to look at, with a single click is much better than the old one, where you had to go back to another page and re-enter info.

4. Appears that the Zapper functinality has been incorporated now? I didn't try it, but it looks like you can submit a comment on a "questionable" observation directly via the data popup window.

There are some things which I would like to see changed/improved:

1. In the observation data popup box, the calendar date should show along with the JD. JD's alone are practically useless for me, and its too much trouble to do a conversion every time I want to get an exact calendar date on an observation. [IMPORTANT]

2. The magnitude in the popup should show with the "less than <" symbol if it is a fainter-than. Right now it shows as a magnitude, just like a positive obs, which could be very confusing and easily result in serious erroneous conclusions. [IMPORTANT]

3. The timeline forward/backward arrows at the bottom don't seem to work properly. Many times they don't move the timeline at all. A few times the backward worked, moving the time a little bit, but the forward did not do anything. Ideally, these arrows should move the entire time "window" back and forth maybe 1/3 or 1/2 of the full displayed time interval on the horizontal scale.

So, these are my initial impressions and criticisms. Overall, I think it is a good improvement over the old one, I will give it a B+ so far :)

Mike L