-
Notifications
You must be signed in to change notification settings - Fork 0
/
GUIDesignGuidelines.html
457 lines (420 loc) · 24.3 KB
/
GUIDesignGuidelines.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>GUI Design Guidelines</title>
<link rel="stylesheet" href="_static/bootstrap-sphinx.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="_static/custom.css" />
<script type="text/javascript" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script type="text/javascript" src="_static/language_data.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="MVP Tutorial" href="MVPTutorial/index.html" />
<link rel="prev" title="Testing Utilities" href="TestingUtilities.html" />
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-59110517-1', 'auto');
ga('send', 'pageview');
</script>
</head><body>
<div id="navbar" class="navbar navbar-default ">
<div class="container">
<div class="navbar-header">
<!-- .btn-navbar is used as the toggle for collapsed navbar content -->
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="http://www.mantidproject.org"><img src="_static/Mantid_Logo_Transparent.png">
</a>
<span class="navbar-text navbar-version pull-left"><b>master</b></span>
</div>
<div class="collapse navbar-collapse nav-collapse">
<ul class="nav navbar-nav">
<li class="divider-vertical"></li>
<li><a href="index.html">Home</a></li>
<li><a href="http://download.mantidproject.org">Download</a></li>
<li><a href="http://www.mantidproject.org">Wiki</a></li>
<li><a href="http://docs.mantidproject.org">User Documentation</a></li>
<li><a href="http://www.mantidproject.org/Contact">Contact Us</a></li>
</ul>
<form class="navbar-form navbar-right" action="search.html" method="get">
<div class="form-group">
<input type="text" name="q" class="form-control" placeholder="Search" />
</div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
</div>
<div class="container">
<div class="row">
<div class="body col-md-12 content" role="main">
<div class="section" id="gui-design-guidelines">
<span id="guidesignguidelines"></span><h1>GUI Design Guidelines<a class="headerlink" href="#gui-design-guidelines" title="Permalink to this headline">¶</a></h1>
<div class="contents local topic" id="contents">
<ul class="simple">
<li><a class="reference internal" href="#summary" id="id2">Summary</a></li>
<li><a class="reference internal" href="#mvp-model-view-presenter" id="id3">MVP (Model View Presenter)</a><ul>
<li><a class="reference internal" href="#model" id="id4">Model</a></li>
<li><a class="reference internal" href="#view" id="id5">View</a></li>
<li><a class="reference internal" href="#presenter" id="id6">Presenter</a></li>
<li><a class="reference internal" href="#testing-mvp-components" id="id7">Testing MVP Components</a></li>
</ul>
</li>
<li><a class="reference internal" href="#visual-design" id="id8">Visual Design</a><ul>
<li><a class="reference internal" href="#qt-designer" id="id9">Qt Designer</a></li>
<li><a class="reference internal" href="#reusable-widgets" id="id10">Reusable Widgets</a></li>
<li><a class="reference internal" href="#icons" id="id11">Icons</a></li>
</ul>
</li>
<li><a class="reference internal" href="#python" id="id12">Python</a><ul>
<li><a class="reference internal" href="#id1" id="id13">Designer</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="summary">
<h2><a class="toc-backref" href="#id2">Summary</a><a class="headerlink" href="#summary" title="Permalink to this headline">¶</a></h2>
<p>This page describes guidelines that should be followed when
implementing an interface in MantidPlot. The aim is to encourage a
consistent approach to developing interfaces.</p>
</div>
<div class="section" id="mvp-model-view-presenter">
<span id="guidesignguidelinesmvpintro"></span><h2><a class="toc-backref" href="#id3">MVP (Model View Presenter)</a><a class="headerlink" href="#mvp-model-view-presenter" title="Permalink to this headline">¶</a></h2>
<p>GUIs in Mantid aim to use the MVP pattern. The MVP pattern is a
generic concept for how to structure GUI code. MVP allows components
of the GUI to be tested separately and automatically. It also allows
for greater flexibility. Decoupling the model and view means that if
the developer wants to experiment with, for example, a different GUI
toolkit, or a different method of doing their calculations, then it is
easy and safe to swap out components. A description of each component
is given below.</p>
<p>To illustrate MVP, a simple example of a calculator GUI has been
created using Python (the concepts of MVP can be applied to any
programming language). This example can be found in
<a class="reference internal" href="MVPTutorial/CalculatorExample/index.html#mvpcalculatorguiexample"><span class="std std-ref">MVP Calculator GUI Example</span></a>, and you can run it with
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">Calculator.py</span></code>.</p>
<p>It is good practice to have model, view or presenter (as appropriate)
at the end of the name for each file (e.g. FFTView, FFTModel,
FFTPresenter), and each component should be a class in its own
right. Within the MVP pattern the model and view never exchange any
information directly.</p>
<div class="section" id="model">
<h3><a class="toc-backref" href="#id4">Model</a><a class="headerlink" href="#model" title="Permalink to this headline">¶</a></h3>
<p>The model is where the ‘hard sums’ take place within GUI. Any Mantid
algorithms should be run in the model, as well any other calculations
that may need to be performed.</p>
<p>It is possible that a presenter may have multiple models. For example
if two GUIs require the same calculation (e.g. mean) but not all
of the model (one GUI may need standard deviation and the other the
median), then it would be sensible for there to be three models (with
the mean model being shared). This prevents code duplication and makes
maintenance easier.</p>
<p>It is important to note that the values used in the calculations
should be received from the presenter (more of which below).</p>
</div>
<div class="section" id="view">
<span id="guidesignguidelinesmvpview"></span><h3><a class="toc-backref" href="#id5">View</a><a class="headerlink" href="#view" title="Permalink to this headline">¶</a></h3>
<p>The view determines the look of the GUI. In passive-view MVP, there
will generally be very little logic in the view. A view should define
the following sections:</p>
<ul class="simple">
<li>The look of the GUI (often this will be defined in a Qt <code class="docutils literal notranslate"><span class="pre">.ui</span></code> file
instead)</li>
<li><strong>Get</strong> methods to return values from the widgets (text input,
checkbox etc)</li>
<li><strong>Set</strong> methods to update the output from the GUI (eg. plot some
data, fill in some text boxes)</li>
</ul>
<p>A view will probably also contain <strong>connections</strong>. A detailed
explanation of signals and slots can be foud <a class="reference external" href="http://doc.qt.io/archives/qt-4.8/signalsandslots.html">here</a>. Briefly, a
widget may emit <strong>signals</strong>. For example QPushButton emits the signal
<code class="docutils literal notranslate"><span class="pre">clicked</span></code> when it is clicked. In order to handle the button being
clicked, the view will implement a <strong>slot</strong> method. This method does
whatever we need for a button click. To ensure that this method is
called whenever the button is clicked, we connect the <code class="docutils literal notranslate"><span class="pre">clicked</span></code>
signal of our button to the <code class="docutils literal notranslate"><span class="pre">handleButtonClick</span></code> slot of our view.</p>
<p>The view should have a parent - this will be the widget containing
it. An example of a parent would be a main window containing tabs -
the children of the main window would be the tabs, and the children of
the tabs would be the widgets contained within the tabs.</p>
</div>
<div class="section" id="presenter">
<h3><a class="toc-backref" href="#id6">Presenter</a><a class="headerlink" href="#presenter" title="Permalink to this headline">¶</a></h3>
<p>The presenter acts as a ‘go-between’. It receives data from the view,
passes it to the model for processing, receives it back from the model
and passes it to the view to be displayed to the user. The presenter
generally should contain relatively simple logic (though it will be
more complex than the view).</p>
<p>The model and the view are stored as members of the presenter
class. These should be passed into the presenter at initialisation.</p>
<p>It is important to note that the model and view should have as little
access as possible to the presenter. Presenter-model communication is
simple - the presenter generally just calls methods on the
presenter. Presenter-view communication is slightly more
involved. There are two ways of doing it:</p>
<ul class="simple">
<li><strong>Connections</strong> - the presenter may contain connections as well as
the view. You may choose to define custom signals in your view, such
as a <code class="docutils literal notranslate"><span class="pre">plotRequested</span></code> signal to announce that the user has asked to
plot some data, probably by clicking a button. The presenter will
need to implement a slot (let’s call it <code class="docutils literal notranslate"><span class="pre">handlePlotRequested</span></code>) to
handle this, which gets the relevant data from the model and passes
it to the view. We then need to connect the signal to the slot in
the presenter’s constructor. It is also possible for a signal
emitted by a view to be caught in the presenter of a parent view. In
order to communicate by connections using Qt in C++ the presenter
must inherit from <code class="docutils literal notranslate"><span class="pre">QObject</span></code>. It’s generally considered good
practice to avoid having Qt in the presenter, so this method works
best for GUIs written in Python (or another language with a more
relaxed type system).<ul>
<li>Note that is good practice to handle all signals in the presenter
if you can, even if it is possible to just handle them in the
view. This is because by going through the presenter we can unit
test the handling of the signals.</li>
</ul>
</li>
<li><strong>Notify</strong> - the presenter may instead allow the view to ‘notify’
it. This can be achieved by implementing a set of possible
notifications (in C++ an enum class works well) and a method
<code class="docutils literal notranslate"><span class="pre">notify(notification)</span></code> on the presenter. In the above example,
<code class="docutils literal notranslate"><span class="pre">handlePlotRequested</span></code> is still needed, but now <code class="docutils literal notranslate"><span class="pre">notify</span></code> invokes
it whenever it is passed a <code class="docutils literal notranslate"><span class="pre">plotRequested</span></code> notification. This
method requires the view to have a pointer to the presenter, which
introduces a circular dependency and leaks information about the
presenter to the view. The leak can be resolved by having the
presenter implement an interface which exposes <strong>only</strong> the
<code class="docutils literal notranslate"><span class="pre">notify</span></code> method, and having the view keep a pointer to
this.</li>
</ul>
<p>Doing presenter-view communication with connections is the cleaner of
the two, so this method should be used unless writing a GUI in
C++. You’ll notice that, in both cases, the view never passes data
(for example, the input from a text box) directly to the presenter,
instead it justs tells the presenter that something needs to be
done. In passive-view MVP the presenter, in handling this, gets any
data it needs from the view using the view’s <strong>get</strong> methods.</p>
</div>
<div class="section" id="testing-mvp-components">
<h3><a class="toc-backref" href="#id7">Testing MVP Components</a><a class="headerlink" href="#testing-mvp-components" title="Permalink to this headline">¶</a></h3>
<p>MVP allows us to write automated tests for a large amount of the
GUI. We can write independent tests for the presenter and model, but
usually not the view (for this reason, the view should be as simple as
possible, ideally containing no logic at all).</p>
<p><strong>Mocking</strong> is very useful tool for testing the presenter. Mocking
allows us to return a predefined result from a method of either the
view or the model.</p>
<p>It is useful to mock out the model because, providing that we’ve
written adequate tests for it, we don’t care what the output is in the
tests for the presenter - we just care that the presenter handles it
correctly. The model may perform time-consuming calculations, such as
fitting, so by returning a dummy value from the fitting method we cut
down the time our tests take to run. We can also potentially change
how the model works - if the GUI uses an algorithm which undergoes
some changes, such as applying a different set of corrections, the
tests for the presenter will be unaffected.</p>
<p>It’s useful to mock out the view because we don’t want to have to
manually input data every time the unit tests are run - instead we can
mock the <strong>get</strong> methods to simulate the user entering data.</p>
<p>Using <a class="reference external" href="https://github.com/google/googletest/blob/master/googlemock/docs/Documentation.md">GMock</a>
in C++, or <a class="reference external" href="https://docs.python.org/3/library/unittest.mock.html">unittest.mock</a> in Python, we
can set expectations in the unit tests for certain methods to be
called, and with certain arguments.</p>
</div>
</div>
<div class="section" id="visual-design">
<h2><a class="toc-backref" href="#id8">Visual Design</a><a class="headerlink" href="#visual-design" title="Permalink to this headline">¶</a></h2>
<div class="section" id="qt-designer">
<h3><a class="toc-backref" href="#id9">Qt Designer</a><a class="headerlink" href="#qt-designer" title="Permalink to this headline">¶</a></h3>
<p>The layout of all interfaces and reusable widgets should be done by
using the Qt’s <a class="reference external" href="http://qt-project.org/doc/qt-4.8/designer-manual.html">Designer</a> tool. This
has several advantages:</p>
<ul class="simple">
<li>immediate visual feedback of what the widget/interface will look
like</li>
<li>far easier to maintain, e.g. moving a control is a simple drag and
drop</li>
<li>reduces the amount of hand-written code required</li>
</ul>
<p>If it is felt that the design must be hand coded then this should be
discussed with a senior developer.</p>
</div>
<div class="section" id="reusable-widgets">
<h3><a class="toc-backref" href="#id10">Reusable Widgets</a><a class="headerlink" href="#reusable-widgets" title="Permalink to this headline">¶</a></h3>
<p>Many interfaces will require similar functionality. For example, the
ability to enter a filename string to search for a file along with a
‘Browse’ button to select a file from the filesystem. This type of
behaviour should be captured in a new composite widget that can be
reused by other components.</p>
<p>The new widget should be placed in the MantidWidgets plugin and a
wrapper created in the DesignerPlugins plugin so that the new widget
type can be used from within the Qt Designer.</p>
<p>The current set of reusable items are:</p>
<table border="1" class="docutils">
<colgroup>
<col width="13%" />
<col width="8%" />
<col width="80%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Class Name</th>
<th class="head">Parent Class</th>
<th class="head">Abiltity</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>AlgorithmSelectorWidget</td>
<td>QWidget</td>
<td>A text box and tree widget to select an algorithm</td>
</tr>
<tr class="row-odd"><td>CatalogSearch</td>
<td>QWidget</td>
<td>An interface interface to the catalog system</td>
</tr>
<tr class="row-even"><td>CatalogSelector</td>
<td>QWidget</td>
<td>Displays the available catalog services</td>
</tr>
<tr class="row-odd"><td>CheckBoxHeader</td>
<td>QHeaderView</td>
<td>Enables checkboxes to exist in the table header</td>
</tr>
<tr class="row-even"><td>ColorBarWidget</td>
<td>QWidget</td>
<td>Show a color bar that can accompany a colored bidimensional plot</td>
</tr>
<tr class="row-odd"><td>DataSelector</td>
<td>MantidWidget</td>
<td>A box to select if input is from a file or workspace along with the appropriate widget to choose a workspace or file.</td>
</tr>
<tr class="row-even"><td>DisplayCurveFit</td>
<td>MantidWidget</td>
<td>A plot to display the results of a curve fitting process</td>
</tr>
<tr class="row-odd"><td>FindReplaceDialog</td>
<td>QDialog</td>
<td>A dialog box to find/replace text within a ScriptEditor</td>
</tr>
<tr class="row-even"><td>FitPropertyBrowser</td>
<td>QDockWidget</td>
<td>Specialisation of QPropertyBrowser for defining fitting functions</td>
</tr>
<tr class="row-odd"><td>FunctionBrowser</td>
<td>QWidget</td>
<td>Provides a wiget to alter the parameters of a function</td>
</tr>
<tr class="row-even"><td>InstrumentSelector</td>
<td>QCombobox</td>
<td>A selection box populated with a list of instruments for the current facility</td>
</tr>
<tr class="row-odd"><td>LineEditWithClear</td>
<td>QLineEdit</td>
<td>A QLineEdit with a button to clear the text</td>
</tr>
<tr class="row-even"><td>MessageDisplay</td>
<td>QWidget</td>
<td>Display messages from the logging system</td>
</tr>
<tr class="row-odd"><td>MWRunFiles</td>
<td>MantidWidget</td>
<td>Provides a line edit to enter filenames and a browse button to browse the file system</td>
</tr>
<tr class="row-even"><td>MWView</td>
<td>QWidget</td>
<td>A colored, bidimensional plot of a matrix workspace</td>
</tr>
<tr class="row-odd"><td>ProcessingAlgoWidget</td>
<td>QWidget</td>
<td>A composite widget that allows a user to select if a processing step is achieved using an algorithm or a Python script. It also provides a script editor.</td>
</tr>
<tr class="row-even"><td>ScriptEditor</td>
<td>QsciScintilla</td>
<td>The main script editor widget behind the ScriptWindow</td>
</tr>
<tr class="row-odd"><td>WorkspaceSelector</td>
<td>QComboBox</td>
<td>A selection box showing the workspaces currently in Mantid. It can be restricted by type.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="icons">
<h3><a class="toc-backref" href="#id11">Icons</a><a class="headerlink" href="#icons" title="Permalink to this headline">¶</a></h3>
<p>Icons are a contentious subject as they can in some cases cause more
confusion and hinder more than they help. The NHS came up with a
good set of rules for what icons should be used and this could be
useful to designers, check out this <a class="reference external" href="https://digital.nhs.uk/blog/transformation-blog/2019/icons-avoid-temptation-and-start-with-user-needs">article.</a>. It may fit a situation more to have a text button
instead of an icon.</p>
<p>Whilst having too many icons will confuse the average user there are
cases where many cases where it would help, for example if a button does a
similar thing to another button somewhere else in the program then
it should have the same icon. Have a look to see if the need you has
an icon in Mantid by look at this handy <a class="reference internal" href="MantidUsedIconsTable.html#mantidusediconstable"><span class="std std-ref">Mantid Icon Table</span></a>.</p>
</div>
</div>
<div class="section" id="python">
<h2><a class="toc-backref" href="#id12">Python</a><a class="headerlink" href="#python" title="Permalink to this headline">¶</a></h2>
<p>Interfaces can also be created in Python using the <a class="reference external" href="https://pypi.org/project/QtPy/">qtpy</a> package. The code for the
interface should be placed in a Python <a class="reference external" href="https://docs.python.org/2/tutorial/modules.html#packages">package</a> under the
<code class="docutils literal notranslate"><span class="pre">Code/Mantid/scripts</span></code> directory. It should be named after the interface
name (without spaces). The code within the package should be
structured to avoid placing all of the code in a single file,
i.e. separate files for different classes etc. Sub packages are
recommended for grouping together logical sets of files.</p>
<p>For the interface to appear from within MantidPlot create a startup
python file under the <code class="docutils literal notranslate"><span class="pre">Code/Mantid/scripts</span></code> directory. Assuming the code
for the interface is in a directory called foo_app then the startup
file would look like:</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">foo_app</span> <span class="kn">import</span> <span class="n">FooGUI</span>
<span class="n">app</span> <span class="o">=</span> <span class="n">FooGUI</span><span class="p">()</span>
<span class="n">app</span><span class="o">.</span><span class="n">show</span><span class="p">()</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">FooGUI</span></code> is the <code class="docutils literal notranslate"><span class="pre">MainWindow</span></code> for the interface. Some more
detailed documentation on creating GUIs in Python can be found at
<a class="reference internal" href="QtDesignerForPython.html#qtdesignerforpython"><span class="std std-ref">Qt Designer for Python</span></a>.</p>
<div class="section" id="id1">
<h3><a class="toc-backref" href="#id13">Designer</a><a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
<p>As with the C++ GUI the Qt Designer should be used for layouts of all
widgets and the main interface. It is recommended that the <code class="docutils literal notranslate"><span class="pre">.ui</span></code>
files be placed in a <code class="docutils literal notranslate"><span class="pre">ui</span></code> subdirectory of the interface package. To
generate PyQt code from the UI xml you will need to run the <code class="docutils literal notranslate"><span class="pre">pyuic4</span></code>
program that ships with PyQt4. It is also recommended that the output
file is named, using the <code class="docutils literal notranslate"><span class="pre">-o</span></code> argument, <code class="docutils literal notranslate"><span class="pre">ui_[widgetname].py</span></code> and
placed in the <code class="docutils literal notranslate"><span class="pre">ui</span></code> subdirectory.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<footer class="footer">
<div class="container">
<ul class="nav navbar-nav" style=" float: right;">
<li>
<a href="TestingUtilities.html" title="Previous Chapter: Testing Utilities"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">« Testing Utili...</span>
</a>
</li>
<li>
<a href="MVPTutorial/index.html" title="Next Chapter: MVP Tutorial"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">MVP Tutorial »</span>
</a>
</li>
<li><a href="#">Back to top</a></li>
</ul>
<p>
</p>
</div>
</footer>
</body>
</html>