Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Mylyn Intent » Mylyn Intent for UI specification(Evaluation of Mylyn Intent...)
Mylyn Intent for UI specification [message #996320] Tue, 01 January 2013 19:29 Go to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 796
Registered: October 2011
Senior Member
I am trying to figure out if I can use Mylyn Intent in oder to write a „user interface specification". In my company, we are programming form-based applications. This kind of specifications is a textual description of the forms.

Take this form as example:
index.php/fa/12857/0/


Basically for each form in each mode (eg edit or new) the description looks like this:
* a title
* some text
* a screenshot
* For each field in the form:
** label
** type of field (text, number, combo, listbox...)
** indication if the field is mandatory
** indication if the field is read only
** textual description of the possible actions (menus, validation rules, specific business logic...)

If I understood Mylyn Intent correctly, this structure is a kind of model ("textual representation") of my forms. Do I need to develop an EMF Model of this?


I have a mechanism to obtain an EMF technical representation of the forms and the fields. Here the EMF Model of the form displayed in the basic tree-editor:
index.php/fa/12858/0/


For the moment this is a semi-automatic process, but I am sure that it can become an automated mechanism. (I know a tool that open each form and take a screenshot from each form. I just need to plug my EMF-Serializer to this tool).

I am also confident that it is possible to map this technical model to the textual representation I want to obtain (but I do not have it yet).


Now the big question:
Do you think that I can use Mylyn Intent for this purpose?

In my opinion, this is near to what Mylyn Intent is doing... I imagine this is a kind of new use-case. I can understand that I might need to develop some configurations / specific document model / extension to Mylyn Intent. If so please, indicate what is currently missing (I need to evaluate the requested time).

If Mylyn Intent is not the tool for a such use-case please tell me.

Thanks a lot for your answer.

.
Re: Mylyn Intent for UI specification [message #997177 is a reply to message #996320] Fri, 04 January 2013 09:44 Go to previous messageGo to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Hi Jeremie,

first of all, thanks for your interest in Intent !
Sorry for the delay, I was in holidays...

What you are trying to do, i.e. synchronizing your software UI with its
documentation, is exactly in Intent scope.

However, as this is a new use case, Intent does not provide the
Synchronization bridge
(http://www.eclipse.org/intent/pages/transcripts/2012_EclipseConEurope/Intent_EConEurope2012.html#28)
allowing to synchronize UI with doc yet.

A "Synchronization bridge" is a piece of code that allows to:
- represent the artifact you want to synchronize with the doc (in your
case, the UI) as an EMF model
- OPTIONAL: detect when the artifact changes, so that synchronization
issues can be detected in real-time. If you do not provide to your
Synchronization Bridge the ability to detect changes, then the
synchronization issues will be detected when the Intent document gets saved.

In a previous post, I detailled how can you write such a Synchronization
bridge
http://www.eclipse.org/forums/index.php/mv/msg/367801/896873/#msg_896873

Please let me know if the explanations are not clear or if you have
trouble implementing your Synchronization bridge. I'm willing to change
the API if needed. I think this would be quite straightforward as you
said you are already able to represent forms as EMF models.

Of course, if you want me to, I would gladly contribute this bridge
directly inside Intent, so that people can use it to document their UI :)

Once the Synchronization bridge is plugged inside Intent, we will be
able to handle such a document :

Section Form1 description {

The Form1 prupose is to ....
* a title
* some text
* a screenshot....

@M
softwareUI {
forms += new Form form1 {
title = 'a title';
text = 'some text';
...
};
}
M@
}

If you change Form1 (from the code or the specifications in the Intent
document), then Intent will raise synchronization issues inside the
model fragment, pointing out the documentation that needs to be updated.

Please let me know if you have further questions, and thanks again !
Alex

Le 01/01/2013 20:29, Jeremie Bresson a écrit :
> I am trying to figure out if I can use Mylyn Intent in oder to write a „user interface specification". In my company, we are programming form-based applications. This kind of specifications is a textual description of the forms.
>
> Take this form as example:
>
>
>
> Basically for each form in each mode (eg edit or new) the description looks like this:
> * a title
> * some text
> * a screenshot
> * For each field in the form:
> ** label
> ** type of field (text, number, combo, listbox...)
> ** indication if the field is mandatory
> ** indication if the field is read only
> ** textual description of the possible actions (menus, validation rules, specific business logic...)
>
> If I understood Mylyn Intent correctly, this structure is a kind of model ("textual representation") of my forms. Do I need to develop an EMF Model of this?
>
>
> I have a mechanism to obtain an EMF technical representation of the forms and the fields. Here the EMF Model of the form displayed in the basic tree-editor:
>
>
>
> For the moment this is a semi-automatic process, but I am sure that it can become an automated mechanism. (I know a tool that open each form and take a screenshot from each form. I just need to plug my EMF-Serializer to this tool).
>
> I am also confident that it is possible to map this technical model to the textual representation I want to obtain (but I do not have it yet).
>
>
> Now the big question:
> Do you think that I can use Mylyn Intent for this purpose?
>
> In my opinion, this is near to what Mylyn Intent is doing... I imagine this is a kind of new use-case. I can understand that I might need to develop some configurations / specific document model / extension to Mylyn Intent. If so please, indicate what is currently missing (I need to evaluate the requested time).
>
> If Mylyn Intent is not the tool for a such use-case please tell me.
>
> Thanks a lot for your answer.
>
Re: Mylyn Intent for UI specification [message #1159988 is a reply to message #997177] Mon, 28 October 2013 22:54 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 118
Registered: November 2010
Senior Member
After a while I am back with my use case:

Here a raw example of the specification we want to obtain:
This comes from my multiple choice example application (MCQS).
QuestionsListForm: <<Questions.pdf>>
AnswerForm: <<Answer.pdf>>

We now have the possibility to scan for the different forms in the application. We obtain a representation of the structure of the application (for the moment the model is hold in memory, but I could imagine instantiate and store an EMF model).

From this representation we make a transformation to obtain a specification of the application. We are working on a way to define what we want to represent in the final documentation (in which order the forms needs to be represented, what we want to display/hide).

And Mylyn Intent in all this?
I could imagine synchronizing this representation of the application with an Intent documentation.

In my opinion, something that is missing in the current documentation model is a way to structure the information. If I understood it correctly, the current documentation model only allows nested text structure. In order to do the transformation correctly I need to do store in my intent documentation more structured text ("here a section representing this form, this form contains this fields...").

1/ What could be a reasonable model for the representation of the application (result of the scanning process)?
=> This model is used in the synchronize view when the doc is out of synch. So I assume you can recommend something.
In the best case scenario I would like to have this model extensible...

2/ How could I store structured text in an Intent document?

I hope we will have time to discuss this at EclipseCon Europe.

.
  • Attachment: Questions.pdf
    (Size: 298.99KB, Downloaded 58 times)
  • Attachment: Answer.pdf
    (Size: 212.84KB, Downloaded 73 times)
Re: Mylyn Intent for UI specification [message #1160056 is a reply to message #1159988] Tue, 29 October 2013 00:00 Go to previous message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Hi Jeremie

funny how this relates with the talk we are giving with Melanie tomorrow
afternoon http://www.eclipsecon.org/europe2013/living-documentation

Basically this is exactly the same idea:
- the formal syntax, instead of describing Forms, describes BDD
Scenarios using a formal Gherkin syntax ("Given", "When", "Then")
- then we generate & synchronize acceptance tests with those specifications

We have to meet to talk about all this, your use case seems valid and
you raise the good questions (the main one I've not implemented yet -
and have ideas for - is the "here a section representing this form"
part, for the time being your formal parsers would be called on all
sections of the Intent document).

See you tomorrow :)
Alex


Le 28/10/2013 23:54, Jeremie Bresson a écrit :
> After a while I am back with my use case:
>
> Here a raw example of the specification we want to obtain:
> This comes from my multiple choice example application (http://code.google.com/a/eclipselabs.org/p/mcqs/).
> QuestionsListForm: <<Questions.pdf>>
> AnswerForm: <<Answer.pdf>>
>
> We now have the possibility to scan for the different forms in the application. We obtain a representation of the structure of the application (for the moment the model is hold in memory, but I could imagine instantiate and store an EMF model).
>
> From this representation we make a transformation to obtain a specification of the application. We are working on a way to define what we want to represent in the final documentation (in which order the forms needs to be represented, what we want to display/hide).
>
> And Mylyn Intent in all this?
> I could imagine synchronizing this representation of the application with an Intent documentation.
>
> In my opinion, something that is missing in the current documentation model is a way to structure the information. If I understood it correctly, the current documentation model only allows nested text structure. In order to do the transformation correctly I need to do store in my intent documentation more structured text ("here a section representing this form, this form contains this fields...").
>
> 1/ What could be a reasonable model for the representation of the application (result of the scanning process)?
> => This model is used in the synchronize view when the doc is out of synch. So I assume you can recommend something.
> In the best case scenario I would like to have this model extensible...
>
> 2/ How could I store structured text in an Intent document?
>
> I hope we will have time to discuss this at EclipseCon Europe.
>
Previous Topic:Intent 0.8 is waiting for your feedback
Next Topic:Mylyn Intent and Papyrus
Goto Forum:
  


Current Time: Thu Nov 27 02:11:02 GMT 2014

Powered by FUDForum. Page generated in 0.01856 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software