[IPOL discuss] web development

[Jean-Michel Morel]

Dear all,

I discussed the matter of hiring a web specialist with Rafael Grompone 
today.

What I write is my (partial) answer, not necessarily his.

I have no opposition to hiring consultants who advise us temporarily. 
But in my opinion it is too early to hire an "IPOL system engineer", 
particularly if he or she had to design anything. If we hire somebody it 
should be a person in charge of maintenance, routine operations, etc, 
not a designer. Because when he or she leaves, what will happen of the 
fancy system?

We have in IPOL a need for six web systems and services

1-a web page publication editor (of, say wikipedia type).
2-a forum management system linked to each article (not yet existing)
3-an on line demo system linked to the web page
4-an archive, linked to the web page
5-a referee, editor, author tracking system (like for other journals).
6-an administration and maintenance of the servers,


In my opinion, 3 and 4 can only be conceived and designed by image 
processing specialists,  and belong to our profession. This is why we 
formed an Editorial Board.

1,2, 5, and 6 should instead, if and when possible, be externalized.

-For 2 for example can we ask a private company to manage the forums for 
us? If yes we should do it, in the same way that labs externalize their 
  email management, for example.

-For 5 the ideal situation would be an agreement with a scientific 
society which manages the submission/referee and editor tracking system, 
independently of the rest. This seems doable. Actually I manage (not 
efficiently) the submissions alone, and it is completely independent of 
the rest 1, 2, 3, 4, 6.

-For 1 the current solution could be changed if we find a better 
web-editing system and again it is independent of the rest.

-For 6 we should also consider externalization of our hardware, when and 
if we can get enough computational power.

I consider that our goal this year is to publish a minimum  of 50 IPOL 
papers. This is the critical size after which  I hope we get a clearer 
picture of a permanent and self-reproducible system and of the permanent 
routine workload it entails.


Best,
Jean-Michel



Nicolas Limare a écrit :
> Hi,
> 
>> I think this raises the question of the web framework. [...]
>> Basically, I think there are three questions:
>>
>> -Should it be a web framework like Django or Rails or should it instead
>> be a content management system (CMS) like typo3 or zope?
> 
> I think a CMS is the quick solution, limited to handle the web
> pages. It comes with its more or less rigid publishing workflow. A web
> framework implied more development work, but will be more flexible and
> extendable.
> 
> So, the real question is not CMS vs Framework, it is more short term
> vs long term, and it is a matter of available workforce.
> 
> For the moment, I chose a CMS (ikiwiki) to have a quickly working IPOL
> prototype. I think from now the correct correct way is the
> framework. Same for the demos. The first version, still used on
> mw.cmla.ens-cachan.fr, was a plain CGI script. The current version
> integrates with a (light) web application framework.
> 
>> -The second question will be on which language the system should run. I
>> think there are at least Ruby, Python, (server side) JavaScript, Perl,
>> PHP and Java. For each language there is at least one system which
>> offers all functionality we need.
> 
> Like everyone, I have some language preferences, but I will resist the
> temptation to start the debate as languages wars are the most common
> and heated (thus often enjoyable yet sterile) discussions among
> programmers...
> 
>> -So I guess the third question is who is going to do the job, because
>> he/she has to invest quite some time to make interactive stuff like
>> forums possible (define styles, install modules/plugins, extend plugins
>> for review-specific workflows, ...).
> 
> First, I think IPOL is still too tied to me, and I think it would be
> healtier if future developments are not done by me, even if I can (and
> intend to) be part of such developments.
> 
> Then, I want to stress a few points, even if some may seem obvious:
> * Some real work is needed, IPOL can't run just from its content
>   authors and reviewers.
> * Web development is more than web editing, it is designing and
>   implementing the published document model (what is an article in
>   IPOL?) and workflow (what are the steps from a draft to a published
>   article, and beyond?).
> * An image processing researcher is not a web developer. Some
>   researchers may be fluent in web publishing, and maybe in web
>   development, but these skills are usually not in the resume of just
>   any computer-savvy researcher.
> 
> So, the best person for IPOL development is probably not one of the
> potential IPOL authors or editors. As proposed by Daniel, a "research
> assistant" may be a possible way. I don't know what's possible on the
> Cachan side. Or other sides (other French labs, Palma, Montevideo,
> ...).
>  
> Jean-Michel, what's your opinion on these questions and the idea and
> possibility of remunerating someone for such works?
> 
> Meanwhile, maybe something can be done to answer Pascal's original
> message, only asking to have the reviews available. Jean-Michel
> answered by asking for forums, then Daniel headed towards general web
> development, but let's be careful not to fail and do nothing because
> of too much ambitions. For the moment, with the existing tools and
> ressources, forums are not possible[1], but it is possible to publish
> the reviewers' comments in a web page accessible from the article
> page.
> 
> Best,
> 
> [1] I thought we could also have forums with the ikiwiki "comment"
> feature, but this proved incompatible with an early IPOL design
> decision: hide and protect all the "active" part of the site behind
> user authentification.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss