How do you usually do this.
We are on a rush.
I came into the project when most layouts were already created.
Developer continues to develop while I develop theme styles straight in a copy (dreaded word) of the solution. There is more than just the styles. I am rearranging some objects. For some, e.g. navbar which I thought I could just remove the one there and then copy paste on all layouts I realize that I might break some underlying code and new stuff added by dev while I was working on ui. Will i have to REPRODUCE everything in dev’s copy?
Huh. That is a challenge . Challenges give us new ideas
What I would do:
work on the same file. FM does not provide tools for updating layouts from external sources.
create a design layout on which are placed objects for each layout item (stiles). This is also great for reviews with the customer and the developer. Centralises layout stuff
once all layout items (styles) are created, walk through each layout and attribute the appropriate style to each layout object
keep a daily planning list of layouts you will work on, share it with the dev in order to avoid conflicts
have a naming convention for styles
P.S. The MBS plugin sorts styles by name in the selector. This is an invaluable help
In the current situation, dev has “sold” a mock/idea to client without waiting for my inputs, THEN asking me for the Theme. We have not taken the time to agree on conventions. Dev objects to working on same file. Dev has lots of pressure as all must be finished by Tuesday morning and he’s still developing. It’s been a rather frustrating experience…
Dev is 25+ years experienced and works fast. However, tends to revert in silo mode. Given my lack of experience and skills level, the relation is rather assymetrical and hard on me because I get a lecture every time I want to do something that dev hasn’t seen before. (Not that what i’m doing is wrong, just doesn’t fit in dev’s rigid concept of the world; so dev requires me to defend my request, need (e.g. nomenclature: I wanted “fillable” and “display” added to “field” objects names) and I simply do not have the profession jargon to argue.
How could this be done in an orderly manner in such a short time?
If the dev objects to working on the same file, you need extra (paid for) time for manual transfer of styles into the target file and working through all layouts and objects.
I guess this is a textbook case example of how not to “collaborate” lol. We have a serious meeting on Wed to discuss before diving in next project.
Hence this thread. Need to arm myself with ideas to improve things.
Some people best work in a 1-person team because they are unable to appreciate and accept other people’s ideas and expertise. This is a personality matter. When such a person also has a powerful position, it is an against-all-odds uphill battle for other team members. Many projects went down the drain because of this.
P.S. experienced devs should neither accept nor dole out silly timelines.
Trust me, dev knows and bites his lips for having done that. Thing is, this is the first step of a 2-3 year project. Client had a hard deadline for that specific app. I'm guilty of having not started the theme before. Having been involved too late in the process took a hit on my motivation. And the fact that I did not know where to begin...
One can create toggled “sticky notes” (I prefer yellow) as markers for comments, changes, reminders, etc., alongside interface objects. Create a global boolean field for developers, a discrete or invisible checkbox on the layout, and each sticky note is hidden or displayed by the calculation when their display is needed. Since you’re not currently working with a shared file however, these notes might only serve yourself but they could be useful none the less.
One can begin or modify a theme’s feedback by using a special, distinctive, reserved color (I prefer orange) as the default for each style category such as edit box, text, part, etc. This technique can readily expose stray objects needing attention.
Over time, experience might show both UI and UX to ultimately rely on only a handful of principles and not “reinventing the wheel.” Yes, be careful of assuming simple objects such as button bars act commonly across layouts because navigating through records may required certain functionality attached at certain times.
I’m curios as to how may tables you’re working with for this project.
I’m working on a tool that compares DDR - and the new XML Copy - and produces a report on the differences objects. When I say working on it - the DDR version is mature but I want to make it multi-user. If you’d like to DM with either DDR or Save a Copy as XML from the two different files I can tell you exactly what has changed: objects, positions, serial numbers, calculations, everything.
Oh my! had not looked at the graph. I'm sure he has Asperger lol. But I must give him lots of credit. It is almost ocd perfectly aligned, named, systematic conventions... If we can iron out communication, roles and control issues, he's a gem to learn from... He codes like a developer (as opposed as improvised citizen developer like me) but that's the issue... I can't match his inside out knowledge of FM and programming skills so if he doesn't let me do my role (ux ui), makes me feel like crap.
I like your sticky notes idea... reminds me of something I saw in philmodjunk's work was wondering what it was lol.
that’s not a easy situation. Collaboration between two individuals needs to work bit ways.
I have been in a situation, not FileMaker development, where I was in charge of developing some modules for a specific device. One day I added to and modify the code and during the next day the other dev made modification on its own - in fact he was always changing his mind. In the end it’S the project that gets penalized.
My guess is that you were assign by someone else to this project, right ? If so, I think you should have a word with your boss about the situation, may be with the other dev to explain the situation. An bot of you needs to synchronized your work with the other.
In a place where I worked, UX-UI developper was the first to work on a project in the analysis phase, and then a file was given to developers with some directions on how to use the UI. Personally when I was facing a need to do a change, I first discussed with the UI-UX developer to get which way I should go - sometimes I needed to explain I can’t use part of the UI because some constraints (scripts, functions, etc.). That worked wonderfully.
In addition, there has to be clear roles. Someone should own the TO and someone should own the layouts. In this case, the other dev may be the owner of everything except themes. @Cecile, if you are the coloring-in person ( no disrespect ) you shouldn’t be making changes to layout objects without a clear OK from the person in charge of that TO/layout.
Dev and I have been considering a work partnership. Initially I was reluctant, mainly because he needs an intermediate and I am a junior without a formal training. He insisted that our strenghts are complementary, mine being the UX and UI.
In the current situation, we are working on his new big client. He is the project owner. He got clearance from the Client to involve me after he had already promised and shown them a first round of mock ups. One Sunday eve, he showed me the mock ups to get my advice. I made a ton of comments and notes. Which he showed the client the next day. Clients were really positive about my comments and asked him to review the mock ups accordingly and I became officially on board (but I never talk to the client; I bill dev).
I was not happy about a few mock ups that I had simply commented “need complete review”. Well since I was not able to spit out a replacement (at this point I did not have much knowledge of the project) right then and there, they were adopted as his, with the UX elements that I felt were not optimal.
Granted, as it is, this app is far superior in terms of architecture (well it works accurately!!) and UX than the one that got canned. So clients are already positive about it.
I guess I’m the one in the wrong and need to chew my socks. I do understand what is at stake and the pressure dev has. It’s hard to figure out my place and how to bring my share since he also controls the UX and UI. In consideration, I’m the colouring gal…
Next project is for my client. We’ll definitely have to discuss how we will work from now on…
The top screen shot is a high level summary showing which catalogs have changed. I clicked on the “modified” link for Layouts and that displayed the second screen which is displayed. That screen shows two tables. The first is the folders/groups that are new, removed, changed or include layouts that have been changed, added or removed. The second is the list of layouts that shows which layouts have been changed, added or removed, and whether the change is to the layout attributes, layout objects or to both.
since working on the same file does not seem to fit, just do a design file
this should be the leading UI-file of your solution, inheriting themes is one-way in FM
as Torsten has already proposed do design layout(s), I usally tend to have 3, a form, a list and a split view or master/detail
this is the only place where changes to themes must be done, afterwards the changed theme can be imported into any solution file, thus the theme stays on the same stage of development
with naming convention everything will be easier espacially working in a team (naming for styles should get it’s own thread )
I developed my naming convention for style between 23:00 and now ;-p
So since I do not have time to style all objects for the morning when he wakes up, I will create and name all of them.
He accepted to work peer to peer tmw so that shall simplify a few things.
That way, I’ll be able to continue developing and he will be able to start using the styles even if they are not good looking, I can change them later.
What I discovered, to my dismay, is that you cannot overwrite a theme by importing one with the same name: filemaker automatically call it whatever2 !!
I might be wrong but I was under the impression that in FMPA prior versions, although we could not do it with built-in themes, it was possible to do that on custom themes. Since this darn file was created in 18, I can’t open it in 17 to test if it is true.
. Challenges give us new ideas 
)