Status of Simile Timeline
89 views
Skip to first unread message
jqueryui-vienna
Mar 25, 2011, 4:22:03 AM3/25/11
to SIMILE Widgets
Hi,
I just wanted to know about the current status of the simile timeline
project. The last commit to its svn trunk was in 2009, so the question
arises if if still is active.
Are there any planned releases or some roadmap?
Franz
I just wanted to know about the current status of the simile timeline
project. The last commit to its svn trunk was in 2009, so the question
arises if if still is active.
Are there any planned releases or some roadmap?
Franz
Alexey Smirnov
Mar 25, 2011, 4:25:06 AM3/25/11
to simile-...@googlegroups.com
Hi,
The community is active, so at least you can ask various questions and
get answers.
Alexey
> --
> You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group.
> To post to this group, send email to simile-...@googlegroups.com.
> To unsubscribe from this group, send email to simile-widget...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en.
>
>
mackenzie
Mar 26, 2011, 8:34:10 AM3/26/11
to SIMILE Widgets
To amplify this a bit, there is no active Time project nowadays
(hasn't been for a couple of years now) but there is an active
community, as Alexey says, who use Timeline and maintain the code. The
only active project going on now that I'm aware of is Exhibit 3
(simile-widgets.org/exhibit3).
MacKenzie
(hasn't been for a couple of years now) but there is an active
community, as Alexey says, who use Timeline and maintain the code. The
only active project going on now that I'm aware of is Exhibit 3
(simile-widgets.org/exhibit3).
MacKenzie
jqueryui-vienna
Mar 28, 2011, 3:37:57 AM3/28/11
to SIMILE Widgets
Sounds almost unbelievable that the Timeline project is frozen... now
that all browsers have enough power to display complex timelines, the
project stops...
that all browsers have enough power to display complex timelines, the
project stops...
Alexey Smirnov
Mar 28, 2011, 3:56:38 AM3/28/11
to simile-...@googlegroups.com
I think Timeline needs a major overhaul. For example, it is beneficial
to use HTML5 drawing capabilities (e.g. Canvas) to render Timeline
instead of using good old div element...
to use HTML5 drawing capabilities (e.g. Canvas) to render Timeline
instead of using good old div element...
Alexey
mackenzie
Mar 28, 2011, 8:52:24 PM3/28/11
to SIMILE Widgets
Timeline isn't "frozen", it's open source software and anyone who
wants to work on it is encouraged to do so. I just meant that no one
at *MIT* isn't currently spending time on it since we're focused on
Exhibit, and that's unlikely to change. If it's needs an overhaul,
find some willing developers to work with the commiters and go for it!
MacKenzie
wants to work on it is encouraged to do so. I just meant that no one
at *MIT* isn't currently spending time on it since we're focused on
Exhibit, and that's unlikely to change. If it's needs an overhaul,
find some willing developers to work with the commiters and go for it!
MacKenzie
codebeneath
Mar 26, 2011, 1:38:11 PM3/26/11
to SIMILE Widgets
Is that to say that the community has commit access to the codebase
for the purposes of addressing filed issues (or applying provided
patches from non-committers)? I am also interested in having the next
release version of Timeline be available for my project and feel that
the orthogonal scrolling as it stands now would warrant a nice project
release for 2.4.0.
Thanks,
Jeff
codebeneath
Mar 28, 2011, 9:41:19 AM3/28/11
to SIMILE Widgets
Is this to say there are several people who have commit access to
Timeline codebase who are addressing filed issues or possibly applying
patches provided via the issue tracker? Of particular interest we
have, we think that the orthoginal scrolling capability alone is
significant enough to warrent a 2.4.0 release. Is there anyone
available who could cut such a release from existing trunk?
Timeline codebase who are addressing filed issues or possibly applying
patches provided via the issue tracker? Of particular interest we
have, we think that the orthoginal scrolling capability alone is
significant enough to warrent a 2.4.0 release. Is there anyone
available who could cut such a release from existing trunk?
LarryK
Apr 10, 2011, 12:11:55 AM4/10/11
to SIMILE Widgets
Hi Everybody,
As the committer who created the last several releases and many many
updates (see the log), here is my take on this question:
Timeline is definitely a current, live, useful, open source project:
* Most importantly, the true status of open source projects are really
defined by their community, not by the software. And Timeline, I'm
proud to say, has a large and vibrant community of people who actively
help out others when they have Timeline questions. (Via this mailing
list.) -- I can't emphasize enough, how important and wonderful this
community is to the project. It is the community that makes a project
come alive and stay alive.
Also:
* The software is used by many many private, public, commercial and
non-commercial sites around the world.
* The software solves a real and active problem very well.
* The software is an important part of a funded MIT project, Exhibit.
To everyone who has helped out someone else via this email list: Thank
you Thank you Thank you!
But...as noted by MacKenzie, Timeline development is not currently
funded by MIT or anyone else.
And, most of the people interested in Timeline want to be users of the
software, not developers of it. (That's fine.)
Also, many of the people interested in further developing the software
don't have the expertise or time for what is needed.
Eg, if you look at the changes log, you'll see some prior commits that
I had to roll back when a change broke the software. This is why I
created the test pages. And more frequently, there have been code
submissions to me that would not work or would break the test pages.
(The changes were submitted via email or the bugs/issues system.)
Plus, integrating a patch into an svn source tree takes a lot of time
if you want to carefully test the proposed changes. So one or two poor
submissions meant that I realized I had to carefully test *all* of the
submissions. Since my time for Timeline is small and decreasing, I had
to prioritize the issues that were important to me. Sorry.
Note that Timeline is what I call "systems-level" software. It is a
large, sophisticated, object-oriented, multi-browser software base.
Making good forward progress with the Timeline code base requires a 4
year CS degree or equivalent, at a bare minimum. Remember that the sw
was written and then re-written by *extremely* bright MIT PhD folks.
This software base isn't for a newbie! (The most surprising
submissions have been from people who tried to work on the minimized
Javascript library instead of using the real source. -- What were they
thinking?)
WHAT'S NEEDED / NEXT STEPS
While the number of qualified developers interested in the Timeline
project is few, it is very important to provide them with the maximum
encouragement! And more importantly, the only way to see if someone's
proposed submission is good is to have a better submission/code
management system. The good news is that such a system exists, git
with github.
Using the git system, anyone can create their own version of the
source tree, make changes to it, then propose to the project
management that their changes be integrated back into the main trunk.
This is how the Yahoo people run their YUI project. They have the same
problem of a sophisticated code base that needs to be carefully
curated.
So the next step, in my opinion, is to move (not fork!) the svn tree
of Timeline and the "Ajax" tree (see the source) to GitHub.
But I need the buy-in and approval of the project leaders David H,
David K, and Stefano before doing that. I'll email them.
PRIORITIES / NEW RELEASES
Yes, certainly the current 2.3.1 release is a bit long in the tooth
and needs to be replaced.
My personal priorities are:
1) Move to github
2) Get the release scripts tuned up and working in the new
environment.
3) Update to current version of JQuery
4) No longer use the "auto-magic" startup code that loads the
libraries and adds them to the dom. Why: current best practice for
quickest page display is to load JS libraries at the end of the page
load, not at the beginning (as stock Timeline does). It is also better
to let the website developer put all Timeline scripts together into
one bigger file rather than smaller files that are auto-loaded. Eg a
current Timeline page loads 4 JS files (ajax, ajax bundle, timeline
bundle, signal). This should be reduced to 1 or 2 (JQuery would be the
second file.)
After that, there are many other bugs to be fixed and features to be
added. Hopefully the community will step up! -- The github move would
really help to enable this. Or I or someone else could be paid to work
on it (that's already happened in the past.)
Comments? Questions?
Regards,
Larry Kluger
ps. I read every bug/issue submission and update. But I just don't
have much time to work on the sw these days. The sw continues to work
very well for me and my projects--I use the current version myself.
pps. Unfortunately, I'm only able to read the mailing list
infrequently.
As the committer who created the last several releases and many many
updates (see the log), here is my take on this question:
Timeline is definitely a current, live, useful, open source project:
* Most importantly, the true status of open source projects are really
defined by their community, not by the software. And Timeline, I'm
proud to say, has a large and vibrant community of people who actively
help out others when they have Timeline questions. (Via this mailing
list.) -- I can't emphasize enough, how important and wonderful this
community is to the project. It is the community that makes a project
come alive and stay alive.
Also:
* The software is used by many many private, public, commercial and
non-commercial sites around the world.
* The software solves a real and active problem very well.
* The software is an important part of a funded MIT project, Exhibit.
To everyone who has helped out someone else via this email list: Thank
you Thank you Thank you!
But...as noted by MacKenzie, Timeline development is not currently
funded by MIT or anyone else.
And, most of the people interested in Timeline want to be users of the
software, not developers of it. (That's fine.)
Also, many of the people interested in further developing the software
don't have the expertise or time for what is needed.
Eg, if you look at the changes log, you'll see some prior commits that
I had to roll back when a change broke the software. This is why I
created the test pages. And more frequently, there have been code
submissions to me that would not work or would break the test pages.
(The changes were submitted via email or the bugs/issues system.)
Plus, integrating a patch into an svn source tree takes a lot of time
if you want to carefully test the proposed changes. So one or two poor
submissions meant that I realized I had to carefully test *all* of the
submissions. Since my time for Timeline is small and decreasing, I had
to prioritize the issues that were important to me. Sorry.
Note that Timeline is what I call "systems-level" software. It is a
large, sophisticated, object-oriented, multi-browser software base.
Making good forward progress with the Timeline code base requires a 4
year CS degree or equivalent, at a bare minimum. Remember that the sw
was written and then re-written by *extremely* bright MIT PhD folks.
This software base isn't for a newbie! (The most surprising
submissions have been from people who tried to work on the minimized
Javascript library instead of using the real source. -- What were they
thinking?)
WHAT'S NEEDED / NEXT STEPS
While the number of qualified developers interested in the Timeline
project is few, it is very important to provide them with the maximum
encouragement! And more importantly, the only way to see if someone's
proposed submission is good is to have a better submission/code
management system. The good news is that such a system exists, git
with github.
Using the git system, anyone can create their own version of the
source tree, make changes to it, then propose to the project
management that their changes be integrated back into the main trunk.
This is how the Yahoo people run their YUI project. They have the same
problem of a sophisticated code base that needs to be carefully
curated.
So the next step, in my opinion, is to move (not fork!) the svn tree
of Timeline and the "Ajax" tree (see the source) to GitHub.
But I need the buy-in and approval of the project leaders David H,
David K, and Stefano before doing that. I'll email them.
PRIORITIES / NEW RELEASES
Yes, certainly the current 2.3.1 release is a bit long in the tooth
and needs to be replaced.
My personal priorities are:
1) Move to github
2) Get the release scripts tuned up and working in the new
environment.
3) Update to current version of JQuery
4) No longer use the "auto-magic" startup code that loads the
libraries and adds them to the dom. Why: current best practice for
quickest page display is to load JS libraries at the end of the page
load, not at the beginning (as stock Timeline does). It is also better
to let the website developer put all Timeline scripts together into
one bigger file rather than smaller files that are auto-loaded. Eg a
current Timeline page loads 4 JS files (ajax, ajax bundle, timeline
bundle, signal). This should be reduced to 1 or 2 (JQuery would be the
second file.)
After that, there are many other bugs to be fixed and features to be
added. Hopefully the community will step up! -- The github move would
really help to enable this. Or I or someone else could be paid to work
on it (that's already happened in the past.)
Comments? Questions?
Regards,
Larry Kluger
ps. I read every bug/issue submission and update. But I just don't
have much time to work on the sw these days. The sw continues to work
very well for me and my projects--I use the current version myself.
pps. Unfortunately, I'm only able to read the mailing list
infrequently.
besiktastan
Apr 10, 2011, 7:46:00 PM4/10/11
to SIMILE Widgets
First and not least, the great work done by Frank and the other past
developers is appreciated and we owe them a lot. I also totally agree
to use the git system with versioning etc.
Regarding the "4) No longer use the "auto-magic" startup code," does
that mean not to use the examples (and the code) at
http://code.google.com/p/simile-widgets/wiki/Timeline_GettingStarted ?
BTW, as far as I can see from the comments and questions from the
community, documentation is the main pain in practice: It is not clear
enough (bundles and files, terminology, localization, etc.), does not
allow community contributions (which would help some users to get
involved into development process), and refers irrelevant code at some
places (e.g. timeline_local_example_1.0.zip is dated Mar 2009). A
reliable documentation is at least as important as the code itself and
Timeline users suffer a lot at this point.
developers is appreciated and we owe them a lot. I also totally agree
to use the git system with versioning etc.
Regarding the "4) No longer use the "auto-magic" startup code," does
that mean not to use the examples (and the code) at
http://code.google.com/p/simile-widgets/wiki/Timeline_GettingStarted ?
BTW, as far as I can see from the comments and questions from the
community, documentation is the main pain in practice: It is not clear
enough (bundles and files, terminology, localization, etc.), does not
allow community contributions (which would help some users to get
involved into development process), and refers irrelevant code at some
places (e.g. timeline_local_example_1.0.zip is dated Mar 2009). A
reliable documentation is at least as important as the code itself and
Timeline users suffer a lot at this point.
LarryK
Apr 10, 2011, 9:39:30 PM4/10/11
to SIMILE Widgets
Hi Besiktastan,
Until things change, continue to use the examples and code on the
getting started page.
But, yes, the changes I have in mind would impact the getting started
sections of the docs. They would then resemble more traditional docs
on using Javascript libraries such as the YUI docs. (Load the
libraries, then call the code.)
I also agree that the documentation needs some luv. A number of people
have been working on it on and off. Your help in improving it would be
greatly appreciated. The current documentation is
http://www.simile-widgets.org/wiki/Reference_Documentation_for_Timeline
it is a wiki -- please create an account, log in, and improve it!
Thanks,
Larry
ps, As far as I know, timeline_local_example_1.0.zip, dated Mar 2009,
is still a good example. Does it not work for you?
Until things change, continue to use the examples and code on the
getting started page.
But, yes, the changes I have in mind would impact the getting started
sections of the docs. They would then resemble more traditional docs
on using Javascript libraries such as the YUI docs. (Load the
libraries, then call the code.)
I also agree that the documentation needs some luv. A number of people
have been working on it on and off. Your help in improving it would be
greatly appreciated. The current documentation is
http://www.simile-widgets.org/wiki/Reference_Documentation_for_Timeline
it is a wiki -- please create an account, log in, and improve it!
Thanks,
Larry
ps, As far as I know, timeline_local_example_1.0.zip, dated Mar 2009,
is still a good example. Does it not work for you?
jqueryui-vienna
Apr 12, 2011, 2:58:09 PM4/12/11
to SIMILE Widgets
Hi Larry,
I'm also one of the content timeline users, I used it in multiple
projects.
I also noticed the vibrant community here. The reason for my worries
were
the de-facto unmaintained state of the project and the complexity of
the timeline software.
Don't get me wrong, the simile timeline is one of the best-coded
javascript projects I've seen so far,
but it definitely needs bright contributors.
Anyway your proposed strategy seems fine for me: move the project to
github, were
people can contribute patches more efficiently and don't put the
stability of the timeline trunk at risk.
For the next commits/releases, I'd go for the low-hanging fruits:
remove the "ancient" timeline script preloader and offer a
timeline.min.js, that can be loaded via lab.js or some other ultra-
efficient preloader. This definitely leads to faster startup times and
will make the users happy :)
regards,
Franz
I'm also one of the content timeline users, I used it in multiple
projects.
I also noticed the vibrant community here. The reason for my worries
were
the de-facto unmaintained state of the project and the complexity of
the timeline software.
Don't get me wrong, the simile timeline is one of the best-coded
javascript projects I've seen so far,
but it definitely needs bright contributors.
Anyway your proposed strategy seems fine for me: move the project to
github, were
people can contribute patches more efficiently and don't put the
stability of the timeline trunk at risk.
For the next commits/releases, I'd go for the low-hanging fruits:
remove the "ancient" timeline script preloader and offer a
timeline.min.js, that can be loaded via lab.js or some other ultra-
efficient preloader. This definitely leads to faster startup times and
will make the users happy :)
regards,
Franz
besiktastan
Apr 14, 2011, 5:57:59 PM4/14/11
to SIMILE Widgets
Thanks for the advice Larry, now I can see that all I have to do is to
improve the wiki of an unstable and not well documented code.
Thanks anyway.
p.s. although timeline_local_example still works, what is wrong with
asking the latest stable release?
improve the wiki of an unstable and not well documented code.
Thanks anyway.
p.s. although timeline_local_example still works, what is wrong with
asking the latest stable release?
Reply all
Reply to author
Forward
0 new messages