Home » Archived » Mylyn Intent » Mylyn Intent for UI specification(Evaluation of Mylyn Intent...)
| Mylyn Intent for UI specification [message #996320] |
Tue, 01 January 2013 19:29  |
 Jeremie Bresson
Messages: 1252
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:
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 #997177 is a reply to message #996320] |
Fri, 04 January 2013 09:44  |
|
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 #1160056 is a reply to message #1159988] |
Tue, 29 October 2013 00:00 |
|
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.
>
|
|
|
Goto Forum:
Current Time: Tue Apr 23 09:43:42 GMT 2024
Powered by FUDForum. Page generated in 0.03543 seconds |
] 
Search
Help
Register
Login
Home
